Message 209286 - Python tracker (original) (raw)

But what problem does it cause if, once in a while, the call takes less than the passed timeout? If that's the case, you'll simply perform another loop, an wake up 1ms later, that's all.

"perform another loop" is my problem. If possible, I would like useless calls to the loop. With my latest patch to asyncio, there is no more useless calls to the loop (at least, not because of a time rounding issue).

Still, you fail to provide an example: you will only perform another call if you pass a tilmeout really close to an exact multiple of the granularity, and the syscall returns early. Just perform a test on your machine, you'll see that early wakeups are really rare. And even if that's the case, I argue that performing an extra loop isn't a problem: for example, noone ever complained about the way timpeouts are rounded in the select module.

If you think otherwise, please back your claim by an example.

Oh, I forgot to mention that I'm also concerned by the backward compatibility. Changing how poll and epoll round the timeout changes the behaviour. It may break applications or maybe change performances of applications (efficiency or reactivity). Changing the rounding method in Python 3.3 was not a good idea.

Don't apply it to 3.3 then.

@Charles-François: I'm not sure that we are talking about the same thing. If you still want to change poll and epoll, go ahead. Since the performance issue has been fixed directly in asyncio, I don't feel the need of changing the poll or epoll anymore in Python 3.4. Or maybe you disagree with my change in the asyncio module?

I disagree with the introduction of a granularity to selectors. If you really want to keep the change in asyncio, just introduce a fixed "slack" value, e.g. 1e-3 seconds.