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