Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126676
Feedback-ID: id5114917:Fastmail
Message-ID: <e65708a0-5130-4726-b405-e3185562d770@rwec.co.uk>
Date: Sun, 9 Mar 2025 13:17:43 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Re: PHP True Async RFC
To: internals@lists.php.net
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <CAMW7n8CAbKRY9RZsJNSnehKVv8NNGtygocxc+zHBS4h9iRyUGA@mail.gmail.com>
 <1b6a5b3b-be9b-4e46-9cc6-b8b7f57b8494@app.fastmail.com>
 <CAMW7n8AumA6bYZ+7+c3rAEeYj0=35wgmohRbrJbH=fc=Ra0FJg@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8AumA6bYZ+7+c3rAEeYj0=35wgmohRbrJbH=fc=Ra0FJg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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]