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 pitrou
Recipients arigo, giampaolo.rodola, gregory.p.smith, gvanrossum, koobs, neologix, pitrou, sbt, vstinner
Date 2013-12-01.00:31:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385857908.2339.13.camel@fsol>
In-reply-to <1385857306.95.0.0854363681007.issue18885@psf.upfronthosting.co.za>
Content
> > I've always had an implicit understanding that calls with timeouts may,
> > for whatever reason, return sooner than requested (or later!), and the
> > most careful approach is to re-check the clock again.
> 
> I've always had the implicit understanding that if I use an *infinite*
> timeout then the call will not timeout.

Wow, that's a good point. select() and friends are not documented to
exhibit successful spurious wakeups. It would be a pretty strong
compatibility breach if they started doing so.

If we don't want select() to silently retry on EINTR, then I think we
should leave it alone.

Speaking of which, I see that SelectSelector.select() returns an empty
list when interrupted, but this is nowhere documented.
History
Date User Action Args
2013-12-01 00:31:51pitrousetrecipients: + pitrou, gvanrossum, arigo, gregory.p.smith, vstinner, giampaolo.rodola, neologix, sbt, koobs
2013-12-01 00:31:51pitroulinkissue18885 messages
2013-12-01 00:31:51pitroucreate