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-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
