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, vstinner
Date 2014-02-07.09:13:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM2ZfAgF1reMXt+BC6gfDC1bzErVpXnF=UriizB18Dw8yQ@mail.gmail.com>
In-reply-to <CAP7+vJK2QUKZdXvBFK4rkEd-rDJd4PZa73TUQ35YCymeqR=Spg@mail.gmail.com>
Content
> 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
History
Date User Action Args
2014-02-07 09:13:32neologixsetrecipients: + neologix, gvanrossum, vstinner
2014-02-07 09:13:31neologixlinkissue20505 messages
2014-02-07 09:13:31neologixcreate