Message 209056 - Python tracker (original) (raw)

Guido van Rossum added the comment:

I've lost some context, but perhaps we should have the notion of "granularity" of the poll/select timeout (e.g. 1 msec), and consider events that are in the future by less than that granularity as ready? Then we can round the timeout down: if someone passes a timeout of 1.1 msec, poll would wait for approximately 1 msec, and when it returns the event would be considered "due now" as long as the balance (about 0.1 msec) was under 1 msec.

Well, it sounds like a good compromise according to my experimentation in my last commits on epoll and selectors.

New attached asyncio_granularity.patch:

I tested the patch on Linux, FreeBSD and Windows (select, selectors and asyncio tests pass). Granularity:

BaseProactorEventLoop doesn't use the resolution of IocpProactor because I don't know the resolution :-) Anyway, time.monotonic() has a low resolution (15.6 ms) and so it should be fine.

If the patch is accepted, my changes on Python 3.3 should also be reverted.