Guido van Rossum added the comment: > Charles-François Natali added the comment:
> Well, I'll change it, but: > We have to change the select() docstring to "Wait until some > registered file objects become ready, or for *at most* timeout > seconds" Doesn't sound so bad to me. It's about the same guarantee as sleep(). > All user code that wants to handle EINTR or correct timeout (which > should be "all user code" in a perfect world) will have to wrap the > call to select() inside a loop equivalent to this decorator, and I > personally like the a rule of "never let the user do what the library > can do for him". No, they'll use a framework with an event loop like Tulip that takes care of all of this for them. Such frameworks all have logic in them to handle early returns from the low-level select/poll operation. I find it easier to reason about the correctness of the framework's code without your decorator: (1) I have to convince myself that the code wrapped by your decorator doesn't change any global state, *or* that there is a guarantee that the exception caught is only raised by the select()/poll()/etc. syscall, not anywhere else in the wrapped method. (2) I have to remember that if a signal handler is called that modifies the event loop's deadline, the selector will return immediately anyway (so the event loop can recalculate its deadline) because of the self-pipe. (3) I have to prove that your decorator uses the same clock as my framework. (4) I have to prove that your code does the same thing if the process is suspended for a really long time and the system clock changes in the meantime. > This includes for example multiprocessing and telnetlib which > currently implement this EINTR handling loop with timeout computation, > see e.g.: > http://hg.python.org/cpython/file/acc7439b1406/Lib/telnetlib.py#l297 > > And other places in the stdlib either don't handle EINTR properly, or > don't re-compute timeout (see e.g. http://bugs.python.org/issue12338). > > Also, I don't really see the problem with retrying upon EINTR, since: > - the signal handler will be called right away anyway > - in case where the select() is a part of an event loop, the event > loop registers a wakup file descriptor with the selector, which means > that upon interesting signal delivery, the select() call will return > to the schedulor > > So in short, I don't see how that could be a nuisance, but I can > certainly see how this could trick user code into raising spurious > timeout-related errors, or be much more complicated than it ought to > be (the above telnetlib example is IMO a great example of why EINTR > and timeout computation should be handled at the selector level). The selector is a helper for higher-level frameworks. I think the EINTR handling belongs in the framework. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16853> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
