Charles-François Natali added the comment: 2013/8/31 Guido van Rossum <rep...@bugs.python.org>: > But still I agree with Giampaolo that the decorator doesn't feel > right. It's like a try/except around the entire body of your function, > which is usually a code smell (even though I realize the exception it > catches can only be raised by the syscall). Please go back to the > explicit try/except returning [].
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" 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". 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). ---------- _______________________________________ 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
