Antoine Pitrou added the comment: > > I've always had an implicit understanding that calls with timeouts may, > > for whatever reason, return sooner than requested (or later!), and the > > most careful approach is to re-check the clock again. > > I've always had the implicit understanding that if I use an *infinite* > timeout then the call will not timeout.
Wow, that's a good point. select() and friends are not documented to exhibit successful spurious wakeups. It would be a pretty strong compatibility breach if they started doing so. If we don't want select() to silently retry on EINTR, then I think we should leave it alone. Speaking of which, I see that SelectSelector.select() returns an empty list when interrupted, but this is nowhere documented. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18885> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
