STINNER Victor added the comment: Le 23 janv. 2014 23:21, e me. > > If epoll_wait(timeout_ms) may wait less than timeout_ms seconds, asyncio > algorithm is wrong, or at least inefficient. It should loop until the time > delta is at least total_timeout seconds. See the original issue: > > http://code.google.com/p/tulip/issues/detail?id=106 > > Not really: sure, an early wakeup can cause spurious loops, but this should > be really rare: how often is the main event loop called with > sub-millisecond timeouts?
Did you read my Tulip? Maybe I didn't explain correctly. Usually, the shorter delay in an application is 10 ms. The problem is that because of the rounding issue (which should now be fixed), the event loop computed a delay smaller than 1 ms. And this delay was rounded to 0 ms by epoll.poll(). Then the deadline was still not reached, the loop was called again... The number of call depends on the performance of your cpu. The high load should be short, probably less than 5 ms, but it occured regulary and was 2totally inefficient. Now asyncio should no more call epoll_wait() in non blocking mode (timeout of 0 ms) if a task is scheduled. So the major inefficient bug is fixed. But it would be nice to ensure that asyncio doesn't loop if nothing happens whereas the deadline is known. For example, it may call again epoll_wait() if it took less than timeout seconds and returned no event, *and* the ready list is empty. For the selector unit test: why does it fail whereas test_epoll has the same test and test_epoll doesn't fail? I fixed the rounding issue in selectmodule.c, but later I made a different fix in selectors which should only be needed for unpatched selectmodule.c. I did that to keep Tulip and Python code identical (including selectors, as asked by Guido). Maybe my rounding formula in selectors.py is wrong? 1e-3 number isn't IEEE 754 friendly, it cannot be stored exactly in binary (in a C double of 64 bits). Maybe the code should be skipped depending on the python version? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20311> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
