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 gvanrossum, neologix, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2014-01-24.07:07:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
I've lost some context, but perhaps we should have the notion of
"granularity" of the poll/select timeout (e.g. 1 msec), and consider
events that are in the future by less than that granularity as ready?
Then we can round the timeout down: if someone passes a timeout of 1.1
msec, poll would wait for approximately 1 msec, and when it returns
the event would be considered "due now" as long as the balance (about
0.1 msec) was under 1 msec.

On Thu, Jan 23, 2014 at 9:36 PM, Charles-François Natali
<> wrote:
> Charles-François Natali added the comment:
>> Did you read my Tulip? Maybe I didn't explain correctly.
> No, it was quite clear, and I think I understand the original issue:
> calling epoll_wait(0) when passed a timeout of 0.9ms was bad, because it
> led to busy-loop during 0.9ms.
> But here, that's another story: once in a blue moon, depending on the
> platform, epoll_wait(1ms) might return after e.g. 0.931ms as above.
> In this case, we'll just call epoll once more with another extra 1ms
> timeout: this doesn't yield excessive CPU usage, only a slight latency, but
> this extra latency is completely normal, since we have to round the delay
> somehow (e.g. if someone passes 0.001ms it will be rounded to 1ms).
> Someone needing high-resolution wakeups shouldn't rely on epoll/select
> timeouts, but use timerfd_create or something similar.
> Furthermore, in practice this shouldn't occur often: if someone passes a
> 1.001 ms timeout, we'll round it to 2ms, so we won't have the problem.
> If someone passes a 0.9ms timeout, it will be rounded to 1ms, so even if
> epoll wakes up a little before 1ms, let's say 0.931ms as in the above
> buildbot failure, it will still be greater than 0.9ms, so no problem either.
> So IMO it's not a problem, and even if it is, there's no reason to
> complicate the code.
> In your test, just restrict the rounding check for delays which are
> strictly less than the underlying syscall resolutuion, e.g. for epoll 1-6,
> 1-5, 1-4. That's enough to check the correct rounding.
>> Maybe my rounding formula in is wrong? 1e-3 number isn't IEEE
>> 754 friendly, it cannot be stored exactly in binary (in a C double of 64
>> bits).
> Regardless of IEEE754 representation, in the end, epoll_wait() is passed an
> integer (a C long).
> So it's either passed 0, 1 or 2. Given the 0.009316698648035526 value, the
> only integer that was possibly passed is 1 (ms), so I don't think rounding
> is the issue.
> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2014-01-24 07:07:22gvanrossumsetrecipients: + gvanrossum, pitrou, vstinner, neologix, python-dev, serhiy.storchaka
2014-01-24 07:07:22gvanrossumlinkissue20311 messages
2014-01-24 07:07:21gvanrossumcreate