This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients gvanrossum, neologix, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2014-01-23.22:21:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM2ZJtsSz6ngmAJSWzNh0+0HdRaENJi6HTf69SRQCYUKXw@mail.gmail.com>
In-reply-to <1390513193.08.0.534894544523.issue20311@psf.upfronthosting.co.za>
Content
> Ah? The manual page of epoll_wait() says:
>
> "The  timeout  argument specifies the minimum number of milliseconds that
epoll_wait() will block.  (This interval will be rounded up to the system
clock granularity, and kernel scheduling delays mean that the blocking
 interval may  overrun  by  a  small  amount.)"
>
> I read minimum, not maximum here :-)

Yes, but we're talking about a 1e-4 accuracy here: I really doubt all
hardware supports high-resolution timers. epoll() returning 1e-4s before
the passed delay doesn't surprise me.

> If epoll_wait(timeout_ms) may wait less than timeout_ms seconds, asyncio
algorithm is wrong, or at least inefficient. It should loop until the time
delta is at least total_timeout seconds. See the original issue:
> http://code.google.com/p/tulip/issues/detail?id=106

Not really: sure, an early wakeup can cause spurious loops, but this should
be really rare: how often is the main event loop called with
sub-millisecond timeouts?
History
Date User Action Args
2014-01-23 22:21:08neologixsetrecipients: + neologix, gvanrossum, pitrou, vstinner, python-dev, serhiy.storchaka
2014-01-23 22:21:08neologixlinkissue20311 messages
2014-01-23 22:21:08neologixcreate