On Sat, Aug 31, 2013 at 9:56 AM, Charles-François Natali
<report@bugs.python.org> wrote:
>
> Charles-François Natali added the comment:
>
> Gregory, thanks, that's what I was planning to do.
>
> But since the recent discussions (mainly on selectors), there are points I obviously don't - and won't - agree with (such as select() returning EINTR or returning early, same for sleep()), I'm not interested in this anymore.

Whoa. Maybe you're overreacting a bit? I personally see a big divide
here between system calls whose functionality includes sleeping (e.g.
sleep(), poll(), select()) and those that just want some I/O to
complete (e.g. recv(), send(), read(), write()). The former are almost
always used in a context that can handle premature returns just fine,
since the return value for a premature return is the same as for
hitting the deadline, and the timeout is often used just as a hint
anyway. It's the latter category (recv() etc.) where the EINTR return
is problematic, and I think for many of those the automatic retry
(after the Python-level signal handler has been run and conditional on
it not raising an exception) will be a big improvement.

> Anyone interested can pick this up, though.
>
> (BTW, as for applications relying on EINTR being returned, I'm positive *way more applications* will break because of the recent change making file descriptors close-on-exec by default).

Again, I'd make a distinction: I agree for send(), recv() etc., but I
don't think there are many buggy uses of select()/poll() timeouts
around. (And even if there are, I still think it's better to fix these
by correcting the retry logic in the framework or the application,
since it may have other considerations.)