> 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.