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 gregory.p.smith
Recipients arigo, giampaolo.rodola, gregory.p.smith, gvanrossum, koobs, neologix, pitrou, sbt, vstinner
Date 2013-12-01.02:47:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAGE7PNKmVJk9oZJ-wr4G5z0pu7ihJxAg-51_DoNM00D6GLHKcQ@mail.gmail.com>
In-reply-to <1385864102.97.0.37491950954.issue18885@psf.upfronthosting.co.za>
Content
Guido's point was that it is already a bug in code to not check the elapsed
time after a select call returns rather than assuming the full timeout time
has elapsed. Correct code today already needs to deal with both situations
(OSError(EINTR) and select returning an empty set before the desired time
has elapsed) because both can happen on existing systems today. So correct
code in the future wishing to be compatible with older Pythons will need to
continue to do so.

As for "presumably have been annoyed by the occasional OSError(EINTR) and
fix that bug" that isn't always true. EINTRs are not guaranteed to happen
and are likely to crop up on different systems (production systems) long
after you've deployed and successfully run your code as they are something
that happens due to things _outside_ of the control of your deployed
program: signals.

That's what has gotten me on a kick to hide EINTR from python developers
when at all possible.

For the record: I am perfectly fine with select and friends returning an
empty set early on EINTR (as Guido seems to prefer). If this worries some
people lets at least highlight this in the documentation as part of this
change.

What I don't want is to ever see OSError(EINTR) in the future.
History
Date User Action Args
2013-12-01 02:47:08gregory.p.smithsetrecipients: + gregory.p.smith, gvanrossum, arigo, pitrou, vstinner, giampaolo.rodola, neologix, sbt, koobs
2013-12-01 02:47:08gregory.p.smithlinkissue18885 messages
2013-12-01 02:47:08gregory.p.smithcreate