On Sun, Mar 9, 2025, at 14:17, Rowan Tommins [IMSoP] wrote:
> 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
Slightly off-topic, but you may find the following article interesting:
https://manybutfinite.com/post/kernel-boot-process/
It's a bit old, but probably still relevant for the most part. At least for x86.
— Rob
