> > 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.