Busy sleep

[davidbrochart]

Correct me if I'm wrong, but sleep will take up 100% CPU. Any idea how to prevent that?

[patrick-kidger]

Right! I'm very aware of this 😄 I believe the usual answer would be to use select/selectors for a notification-based system on when to wake up the loop.

That said I think this might be overkill for us: the real reason for this is when working with run_in_thread, where we are essentially just polling to see if the thread is done. If this didn't exist then it wouldn't be too tricky to just have the loop know when all calls are a sleep, and for the loop itself to then time.sleep until they are complete.

But the thread issue can be solved in other ways, e.g. by having all threads put their work on a queue, with the loop then blocking on queue.Queue.get.

I'm noodling this one over a bit. If it can still be done succinctly then there'd be no harm in improving things that way.

[davidbrochart]

I believe the usual answer would be to use select/selectors for a notification-based system on when to wake up the loop.

But wouldn't that require a thread? If so, then why not just time.sleep in a thread?

[patrick-kidger]

Okay, so I got completely nerd-sniped into tackling this today. Take a look at #7, which should no longer use a busy loop.

On 'why not just time.sleep in a thread', it's basically just that this wouldn't be enough -- we'd still be polling for whether the thread has completed. (This is why I mention threads above.)

As it turns out, in #7 I do in fact refactor sleep to run in a thread instead :) Alongside replacing all polling with an Event system. Ultimately the loop should now just find itself blocking on a single threading.Event.wait in all scenarios that it would previously poll until a condition is met. (I've not seriously stress-tested this branch yet, so I'd appreciate any feedback on it.)