Charles-François Natali added the comment: > 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20505> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com