249b4b9 has introduce(d) back to immediately run continuations whilst resuming from a (potentially) blocked event loop (virtual) thread: this can help to immediately pick the continuation and run it, without waiting all the I/O to happen.
At the same time we risk to delay any non blocking tasks of the event loop (and I/O tasks too, since "padded" by running immediately continuation(s).
Due to it, the immediate running feature could be improved by tracking the overall accumulated latencies while the continuations runs with running == false and give up on it if exceeding some configurable limit
e.g. after an overall 100 ms accumulated delay due to running immediately continuations, we stop running them and just enqueued awaiting the next chance (i.e. when running == true).