If you fix this in selectors.py (as opposed to the C extensions) the
fix is (nearly) automatically incorporated in Tulip for Python 3.3.

On Mon, Jan 20, 2014 at 2:53 AM, Victor Stinner
<[email protected]> wrote:
> Hi,
>
> I tried to compare Tulip and Trollius, to try to understand how "yield
> from" is different from "yield". I wrote the following script:
> https://bitbucket.org/haypo/asyncio_staging/src/47a0b9c/event_loop_run_once.py
>
> When I replaced asyncio.sleep(1.0) with asyncio.sleep(0.1), I saw more
> than 50 calls to _run_once() wheras only 4 calls are required with a
> sleep of one second.
>
> Example with a sleep of 100 milliseconds:
> - Tulip computes a deadline of 99.98 milliseconds, epoll_wait() is
> called with a timeout of 99 ms
> - Timeout, but the scheduled task is not scheduled because there is
> still a difference of 0.6 milliseconds
> - Tulip computes a deadline of 0.47 ms, epoll_wait() is called with a
> timeout of... 0 ms
> - Timeout, but the scheduled task is not scheduled because there is
> still a difference of... 0.3 milliseconds
> - etc. until the timeout is reached
>
> The number of iterations depends on the speed of your CPU. For
> example, a dummy loop calling sleep(1e-3) ten times calls _run_once()
> 918 times on my laptop...
>
> The problem is that the C function epoll_wait() expects a C int for
> the timeout, which is a number of milliseconds. So 99.98 ms should be
> rounded to *100* ms, and 0.47 ms must be rounded to 1 ms.
>
> In my opinion, it's a bug in CPython: epoll.poll(timeout) should wait
> *at least* timeout seconds, but not *less*.
>
> I reported the issue in CPython:
> http://bugs.python.org/issue20311
>
> Even if the bug in fixed in Python 3.4 and the next release of Python
> 3.3, Tulip should works around this bug to support older Python 3.3
> released. So I also also posted a patch for Tulip:
> code.google.com/p/tulip/issues/detail?id=106
>
> Victor



-- 
--Guido van Rossum (python.org/~guido)

Reply via email to