Gregory P. Smith 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.
exactly. at the system call level you can be interrupted. re-checking the
clock is the right thing to do if the elapsed time actually matters.
> If we don't want select() to silently retry on EINTR, then I think we
should leave it alone.
We should go ahead and retry for the user for select/poll/epoll/kqueue. If
they care about being able to break out of that low level call due to a signal,
they should set a signal handler which raises an exception. I have *never*
seen code intentionally get an EINTR exception from a select or poll call and
have often seen code tripped up because it or a library it was using forgot to
handle it.
We're a high level language: Lets be sane by default and do the most desirable
thing for the user. Retry the call internally with a safely adjusted timeout:
new_timeout = min(original_timeout, time_now-start_time)
if new_timeout <= 0:
return an empty list # ie: the system clock changed
retry the call with new_timeout
----------
_______________________________________
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
