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
<report@bugs.python.org> 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 selectors.py 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 <report@bugs.python.org>
> <http://bugs.python.org/issue20311>
> _______________________________________