Guido van Rossum added the comment: 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 < rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue20505> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20505> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
