OK, this sounds like rounding up is important to avoid busy-wait (but maybe
only when rounding down would give us zero), and we shouldn't have to worry
about a courser timer, it will just make us late and that's always
acceptable.

On Fri, Feb 7, 2014 at 1:13 AM, Charles-François Natali <
report@bugs.python.org> wrote:

>
> Charles-François Natali added the comment:
>
> > How sure are you? Suppose I use poll() with a 0.5 msec timeout. This
> > presumably gets rounded up to 1 msec. But if the system clock has e.g. a
> 10
> > msec resolution, won't this still wait 0 msec? Or will it wait until the
> > next "tick" occurs, which could be anywhere between 0 and 10 msec in the
> > future?
>
> It depends :-)
> With high-resolution timers, you'll get 1ms.
> Without, you'll likely get 10ms (time quantum).
> An implementation returning without delay would be seriously broken.
>
> > But if so, why wouldn't a poll() with a 0 msec timeout also wait
> > between 0 and 10 msec?
>
> Because the kernel doesn't suspend the current task/thread, it just checks
> the list of currently FDs, and returns immediately.
> See e.g.
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/select.c?id=797a796a13df6b84a4791e57306737059b5b2384#n772
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue20505>
> _______________________________________
>