Description
Since #8030 the dev variant yields 'random' test failures for uasyncio, probably depending on machine/version/...
For example on my machine the uasyncio_basic consistently prints took 30 50 0 as last line, instead of the expected took 20 40 0. Some builds of the mingw port also fail in Appveyor for me. The reason for this is mentioned in #7796 :
most likely all sleep/wait implementations on windows by default use a 16mSec (or close to that) resolution
The dev variant enables both uasyncio and the scheduler, and uasyncio calls poll_poll_internal and that uses MICROPY_EVENT_POLL_HOOK which in turn calls mp_hal_delay_us(500). That last one is the culprit.
Setting MICROPY_ENABLE_SCHEDULER to 0 leaves MICROPY_EVENT_POLL_HOOK undefined, so doesn't compile because moduselect.c uses that unconditionally. Just adding #define MICROPY_EVENT_POLL_HOOK fixes that. It also makes the uasyncio tests pass. But it also turns poll_poll_internal into a busy loop. Likewise for mp_hal_delay_ms because it's conditional on ifdef MICROPY_EVENT_POLL_HOOK which should argueably should be #if MICROPY_ENABLE_SCHEDULER.
Things also grew a bit messy over time with there being multiple ways to sleep on Windows: mp_hal_delay_ms calls SleepEx but mp_hal_delay_us uses an implementation which uses which uses a timer. Which I wrote, but I don't remember why: I don't think it's better/worse/very different from SleepEx. Could be that things used to be different back then. Anyway these 2 should be consolidated.
Then the question remains how to fix this
- I don't hink having busy waits is ok, even though they will make everything work and do so fairly accurately.
- by default there's just no accurate wait on windows. We could work with that, add a word of warning to the README, and change the tests so they pass
- figure out a way to make the wait accurate. I know at least one but it's generally considered bad practice (because https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/). There might be other ways though, not sure.