Author vstinner
Recipients georg.brandl, gvanrossum, neologix, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2014-01-25.21:24:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwbTnRQx_68fBwQN=M8hx_XEqbDic9zsUhYV-VV7wi6aGQ@mail.gmail.com>
In-reply-to <CAH_1eM23Sh+r_Lrz7kzsC4XrE=syz6DHuBDRPE_jcYaFJ2LnoA@mail.gmail.com>
Content
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
History
Date User Action Args
2014-01-25 21:24:17vstinnersetrecipients: + vstinner, gvanrossum, georg.brandl, pitrou, neologix, python-dev, serhiy.storchaka
2014-01-25 21:24:17vstinnerlinkissue20311 messages
2014-01-25 21:24:17vstinnercreate