Prioritize correctly event loop's resume #14
Description
In this scenario:
- few enqueued ready to execute virtual threads
- the event loop contend against some shared resource (from outside) or has a short timeout with NIO's select (due to some scheduled async timer)
- it will cause the custom scheduler to suspend it (for later resume)
- the resume request is issued (to the scheduler i.e. as a request to resume the event loop), but if the carrier is executing other continuations, it won't be promptly picked (e.g. it takes 1 us of reaction time)
This is happening because usually, on Thread::yield on the event loop, the event loop is immediately submitted (before we run ANY continuations), making a bit messy to detect when we have urgency to resume it vs an expected interleaving/context switch i.e. Thread::yield.
In short, we would like to distinguish when we are yielding on purpose from the event loop (e.g. in the Thread::yield case) from when we have been notified while executing continuations that we have to resume it back.