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 <rep...@bugs.python.org> <http://bugs.python.org/issue20311> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
