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 vstinner
Recipients gvanrossum, neologix, python-dev, vstinner
Date 2014-01-31.10:45:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1391165116.99.0.585988897251.issue20452@psf.upfronthosting.co.za>
In-reply-to
Content
> Just round the timeout away from 0 and be happy: this will fix the busy-wait problem, and that's all we want.

I didn't work, see:
http://bugs.python.org/issue20311#msg208601

> Once again, I know I keep repeating myself, but having select/epoll/whatever wake up 10usec before the timeout isn't an issue: *all* async-IO frameworks out there work just fine with this.

The previous issue #20311 and this one are not critical bug, just performance issues. I would prefer to not call _run_once() and epoll_wait() too many times if it's useless (if it can be avoided).

> So please, revert all this granuarity complexity, and re-apply the timeout rounding.

*If* we come back to the rounding aways zero option and granularity is removed from asyncio.BaseEventLoop, the issue should also be fixed in the IOCP selector used by the proactor event loop in Python.

--

If we decide that it's not an issue that _run_once() is called too many times, the unit test can be changed to ensure that _run_once() is called less than 10 times, instead of expecting an exact number of calls (7 at the end): so tolerate 3 useless calls.
History
Date User Action Args
2014-01-31 10:45:17vstinnersetrecipients: + vstinner, gvanrossum, neologix, python-dev
2014-01-31 10:45:16vstinnersetmessageid: <1391165116.99.0.585988897251.issue20452@psf.upfronthosting.co.za>
2014-01-31 10:45:16vstinnerlinkissue20452 messages
2014-01-31 10:45:16vstinnercreate