Timings on my laptop:

>>> import time, select
>>> t0=time.perf_counter(); select.select([], [], [], 1e-6); dt=time.perf_counter()-t0; dt
([], [], [])
0.00012494399561546743
>>> t0=time.perf_counter(); select.select([], [], [], 0); dt=time.perf_counter()-t0; dt
([], [], [])
4.965400148648769e-05

A call to select.select() with a timeout of 1 microsecond (10^-6) takes 124 microesconds.

A non-blocking call to select.select() (timeout of 0 microsecond) takes 50 microseconds.

> Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)...

Yes, the problem of asyncio (explained in issue #20311) is that selector.select(timeout) took *less* than timeout seconds even when no new event was found, and so the loop restarted again and again.

According to the timings above, selector.select(1e-7) (which calls currently select.select() in non blocking mode, with a timeout of 0 second) takes longer than 1e-7 second: at least 500e-7 seconds. So yes, the problem cannot be reproduced on my current hardware.

It may be fine to only fix these bugs in Python 3.5.