Hi,

2014-01-25 Charles-François Natali <report@bugs.python.org>:
> I'm sorry, but I'm not convinced.
> The selector's granularity is an implementation detail, and I don't think
> it should be exposed.

I disagre, it's not a detail because it causes bugs, knowing the
resolution matters.

> Furthermore, it's not a mere function of the C type used to represent the
> timeout to the underlying syscall (long, timeval): it also depends on the
> operating system, the hardware, etc.

I exposed the resolution of the underlying C structure, I know that it
doesn't guarantee anything. But we did the same thing for clocks with
time.get_clock_info(name).resolution.

At least, if the C structure has a resolution of 1 ms, don't expect to
have a resolution better than 1 ms in practice. It's better than not
knowing it.

The OS limitations can be documented.

> Once again, what's wrong with your initial approach of ceiling the timeout?

It looks like changing the rounding method doesn't solve anything.
selector.select(timeout) may still take less than timeout, so it
doesn't give any guarantee.

IMO adding a granularity to asyncio is a better approach. asyncio can
for example adjusts its granularity at runtime if it see that the
announced selector resolution is wrong. And the granularity also uses
the clock resolution.

Victor