On 08/03/2025 20:22, Edmond Dantes wrote:
For coroutines to work, a Scheduler must be started. There can be only one Scheduler per OS thread. That means creating a new async task does not create a new Scheduler.
Apparently, async {} in the examples above is the entry point for the Scheduler.
I've been pondering this, and I think talking about "starting" or "initialising" the Scheduler is slightly misleading, because it implies that the Scheduler is something that "happens over there".
It sounds like we'd be writing this:
// No scheduler running, this is probably an error
Async\runOnScheduler( something(...) );
Async\startScheduler();
// Great, now it's running...
Async\runonScheduler( something(...) );
// If we can start it, we can stop it I guess?
Async\stopScheduler();
But that's not we're talking about. As the RFC says:
Once the Scheduler is activated, it will take control of the Null-Fiber context, and execution within it will pause until all Fibers, all microtasks, and all event loop events have been processed.
The actual flow in the RFC is like this:
// This is queued somewhere special, ready for a scheduler to pick it up later
Async\enqueueForScheduler( something(...) );
// Only now does anything actually run
Async\runSchedulerUntilQueueEmpty();
// At this point, the scheduler isn't running any more
// If we add to the queue now, it won't run unless we run another scheduler
Async\enqueueForScheduler( something(...) );
Pondering this, I think one of the things we've been missing is what Unix[-like] systems call "process 0". I'm not an expert, so may get details wrong, but my understanding is that if you had a single-tasking OS, and used it to bootstrap a Unix[-like] system, it would look something like this:
1. You would replace the currently running single process with the new kernel / scheduler process
2. That scheduler would always start with exactly one process in the queue, traditionally called "init"
3. The scheduler would hand control to process 0 (because it's the only thing in the queue), and that process would be responsible for starting all the other processes in the system: TTYs and login prompts, network daemons, etc
I think the same thing applies to scheduling coroutines: we want the Scheduler to take over the "null fiber", but in order to be useful, it needs something in its queue. So I propose we have a similar "coroutine zero" [name for illustration only]:
// No scheduler running, this is an error
Async\runOnScheduler( something(...) );
Async\runScheduler(
coroutine_zero: something(...);
);
// At this point, the scheduler isn't running any more
It's then the responsibility of "coroutine 0", here the function "something", to schedule what's actually wanted, like a network listener, or a worker pool reading from a queue, etc.
At that point, the relationship to a block syntax perhaps becomes clearer:
async {
spawn start_network_listener();
}
is roughly (ignoring the difference between a code block and a closure) sugar for:
Async\runScheduler(
coroutine_zero: function() {
spawn start_network_listener();
}
);
That leaves the question of whether it would ever make sense to nest those blocks (indirectly, e.g. something() itself contains an async{} block, or calls something else which does).
I guess in our analogy, nested blocks could be like running Containers within the currently running OS: they don't actually start a new Scheduler, but they mark a namespace of related coroutines, that can be treated specially in some way.
Alternatively, it could simply be an error, like trying to run the kernel as a userland program.
--
Rowan Tommins
[IMSoP]