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