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, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2014-01-23.23:04:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwZ7TrkV1EGk0=BaDg_BaD8HMM0asvSWP3gk25nx6sDbaQ@mail.gmail.com>
In-reply-to <CAH_1eM2ZJtsSz6ngmAJSWzNh0+0HdRaENJi6HTf69SRQCYUKXw@mail.gmail.com>
Content
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?
History
Date User Action Args
2014-01-23 23:04:38vstinnersetrecipients: + vstinner, gvanrossum, pitrou, neologix, python-dev, serhiy.storchaka
2014-01-23 23:04:38vstinnerlinkissue20311 messages
2014-01-23 23:04:35vstinnercreate