Guido van Rossum added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue20311> > _______________________________________ ---------- _______________________________________ 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
