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 neologix
Recipients gvanrossum, neologix, vstinner
Date 2014-02-05.19:56:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1ErWvdLyu30jCwUc0xWZ73sUM54FFs=MHsLEbqXv6n6g@mail.gmail.com>
In-reply-to <1391470456.74.0.460953910028.issue20505@psf.upfronthosting.co.za>
Content
> To solve a performance issue in asyncio, I added a new resolution
attribute to selectors.BaseSelector and a new _granularity attribute to
asyncio.BaseEventLoop. If I understood correctly, Charles-François (author
and so maintainer of the new selectors module) doesn't like the new
resolution attribute because it is a lie (if I understood correctly
Charles-François complain).

Here are the reasons I don't like this attribute:
- it's a low-level implementation detail, which shouldn't be part of the API
- it's actually impossible to provide a sensible value for the granularity,
because it depends not only on the operating system, but also on the actual
version on the OS, and the hardware, as Victor's extensive tests showed
- what's the definition of this "granularity" anyway?
- but most importantly, it's useless: the performance problem initially
identified was due to the rounding of select/epoll/etc of timeouts towards
zero, which means that it they got passed a timeout smaller than the
syscall resolution, the syscall would end up being called in a tight loop.
Now that the timeouts are rounded away from 0, that's not an issue anymore

Let me state this last point once again: no busy loop can occur now that
timeouts are rounded up.
Sure, some syscalls, on some OS, can sometimes return a little bit earlier
than expected, e.g. epoll can return after 0.98ms instead of 1ms. But
that's not an issue, if that's the case you'll just loop an extra time,
*all* event loops just work this way.
Furthermore, note than due to rounding, the actual probability of having
the syscall return earlier than expected is really low:
for example, if the loop wants to wake up in 5.3ms, it will be rounded to
6ms, and even a slight early wakeup won't be enough to wake up before 5.3ms
(typically it'll return after 5.98ms or so).

 > The patch is a comprise, it solves partially the asyncio performance
issue. With the patch, BaseEventLoop._run_once() may not executed a task
even if there was a scheduled task, just because of timing rounding issues.
So I modified the existing patch to tolerate "useless calls" to _run_once().

If you want to keep the current approach, nothing prevents from using a
fixed "slack" value, independant of the selector (e.g. 1ms seems
reasonable).
History
Date User Action Args
2014-02-05 19:56:18neologixsetrecipients: + neologix, gvanrossum, vstinner
2014-02-05 19:56:18neologixlinkissue20505 messages
2014-02-05 19:56:17neologixcreate