This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients gregory.p.smith, gvanrossum, neologix, pitrou, sbt, vstinner
Date 2013-08-31.17:19:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJK2kb1DOmxx+0zoD+y=+45FV7N7R-FZSS=HD-ErOvCQMA@mail.gmail.com>
In-reply-to <1377968189.2.0.575176543025.issue18885@psf.upfronthosting.co.za>
Content
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.)
History
Date User Action Args
2013-08-31 17:19:22gvanrossumsetrecipients: + gvanrossum, gregory.p.smith, pitrou, vstinner, sbt
2013-08-31 17:19:22gvanrossumlinkissue18885 messages
2013-08-31 17:19:21gvanrossumcreate