STINNER Victor added the comment: Timings on my laptop:
>>> import time, select >>> t0=time.perf_counter(); select.select([], [], [], 1e-6); >>> dt=time.perf_counter()-t0; dt ([], [], []) 0.00012494399561546743 >>> t0=time.perf_counter(); select.select([], [], [], 0); >>> dt=time.perf_counter()-t0; dt ([], [], []) 4.965400148648769e-05 A call to select.select() with a timeout of 1 microsecond (10^-6) takes 124 microesconds. A non-blocking call to select.select() (timeout of 0 microsecond) takes 50 microseconds. > Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 > or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes > some time)... Yes, the problem of asyncio (explained in issue #20311) is that selector.select(timeout) took *less* than timeout seconds even when no new event was found, and so the loop restarted again and again. According to the timings above, selector.select(1e-7) (which calls currently select.select() in non blocking mode, with a timeout of 0 second) takes longer than 1e-7 second: at least 500e-7 seconds. So yes, the problem cannot be reproduced on my current hardware. It may be fine to only fix these bugs in Python 3.5. ---------- versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20320> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
