STINNER Victor added the comment: Results on "x86 Gentoo 3.x" buildbot:
[136/389] test_asyncio WARNING: selector.select(timeout=0.09997069113887846470) took dt=0.09961039200425148010 sec (dt-timeout=-0.00036029913462698460) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.09995610709302127361) took dt=0.09992253710515797138 sec (dt-timeout=-0.00003356998786330223) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.00994763919152319431) took dt=0.00972709804773330688 sec (dt-timeout=-0.00022054114378988743) WARNING: dt+0.00100000000000000002 > timeout? True Ok, it looks better: waiting 99.9 ms took 99.6 ms and 99.9 ms, and waiting 9.9 ms took 9.7 ms. So as I said, the granularity (of 1 ms) is still needed in asyncio (dt < timeout is sometimes False, but dt+granulary >= timeout is always True). We could round the timeout by adding 2 ms in epoll.poll(), but it would be inefficient: it reduces the accurary of 1 ms, whereas the change would only be needed by asyncio. IMO the granularity rounding is better because it uses also the resolution of the clock, which matters a lot on Windows whereas time.monotonic() has a resolution of 15.6 ms. There are same results on "x86 Gentoo Non-Debug 3.x" and "x86 Ubuntu Shared 3.x" buildbots. -- In test_signal_handling_args, dt+granularity > timeout is still True, because the selector was interrupted by a signal. For this case, loop_run_once.patch avoids a second call to _run_once(), but in fact it doesn't optimize anything (calling _run_once() again is just the same). Calling _run_once() again if selector was interrupted is just fine IMO. Example of interrupted selector: WARNING: selector.select(timeout=0.49998722597956657410) took dt=0.10003586183302104473 sec (dt-timeout=-0.39995136414654552937) WARNING: dt+0.00100000000000000002 > timeout? False -- For time handling on Linux, see also: http://www.python.org/dev/peps/pep-0418/#linux-clocksource ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20452> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
