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