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, python-dev, vstinner
Date 2014-02-07.19:25:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0M8-rK-d2TARD0wwfDMP8V+o=J9oUqFcTLKaaMbHT=PQ@mail.gmail.com>
In-reply-to <1391791172.15.0.661382377277.issue20505@psf.upfronthosting.co.za>
Content
> select() and kqueue() are able to sleep less than 1 ms. Using a slack of
1 ms would reduce the accuracy. I don't see why we should limit the
accuracy. Why 1 ms? Because of poll/epoll? What about Windows and its
resolution of 15.6 ms?
>
> Well, under 1 ms, don't expect accurate results :-) For example on my
fast Linux box, a select() with a timeout of 61 us takes 137 us (elapsed
time measued in Python).

That's precisely why I suggested 1ms.

And, by definition, it would only be used if the select()/poll() call
returns earlier in the first place, so it doesn't reduce the accuracy.

> I would like to avoid this *useless* loop, because such case can be
common.
> What's the point of polling again? We just polled all file descriptors.

"If it ain't broke, don't fix it": for the 10th time, all event loops work
like this, and this has *never* been an issue.
So I suggest we stop making up complicated solutions to non-existent
problems.
History
Date User Action Args
2014-02-07 19:25:50neologixsetrecipients: + neologix, gvanrossum, vstinner, python-dev
2014-02-07 19:25:49neologixlinkissue20505 messages
2014-02-07 19:25:49neologixcreate