Author vstinner
Recipients gvanrossum, neologix, pitrou, serhiy.storchaka, vstinner
Date 2014-01-20.10:33:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za>
In-reply-to
Content
Hi, while comparing performances of Tulip and Trollius projects (asyncio module), I found a bug. The event loop is called too many times when a callback is scheduled with a timeout and the epoll selector is used, especially for timeout close to one millisecond.

In my opinion, it's a bug in epoll.poll(): it should wait *at least* timeout seconds if no event is received, not shorter.

Pseudo-code of Tulip:
---
timeout = scheduled[0].when - time.monotonic()
events = selector.select(timeout)
process_events(events)
while scheduled:
   if scheduled[0].when > time.monotonic():
      break
   ...
---

The problem is that "scheduled[0].when > time.monotonic()" test fails because epoll.poll() returns in less than timeout seconds.

The difference between the timeout and elapsed time is very small, less than 1 millisecond.

Attached patch fixes this issue by rounding the timeout to the upper bound.

The rounding is different than datetime.timedelta constructor for example, because the usecase is different. epoll.poll(0.0001) calls epoll_wait() with a timemout of 1 millisecond (1e-4 rounded to 1e-3).

epoll.poll(0.0) still calls epoll_wait() with a timeout of 0 millisecond. I don't think that it's possible to write a reliable unit test for that on our slow buildbots.
History
Date User Action Args
2014-01-20 10:33:28vstinnersetrecipients: + vstinner, gvanrossum, pitrou, neologix, serhiy.storchaka
2014-01-20 10:33:28vstinnersetmessageid: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za>
2014-01-20 10:33:28vstinnerlinkissue20311 messages
2014-01-20 10:33:27vstinnercreate