[issue18885] handle EINTR in the stdlib
Gregory P. Smith
report at bugs.python.org
Sun Dec 1 02:10:14 CET 2013
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 <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________
More information about the Python-bugs-list
mailing list