Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126682
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 09 Mar 2025 23:04:40 +0100
To: internals@lists.php.net
Message-ID: <4305eda7-0fa7-4dd4-a7ff-131cf1c82e51@app.fastmail.com>
In-Reply-To: <e65708a0-5130-4726-b405-e3185562d770@rwec.co.uk>
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>
 <e65708a0-5130-4726-b405-e3185562d770@rwec.co.uk>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC
Content-Type: multipart/alternative;
 boundary=f70ec8ad9be54116aaa1f9c976687fa8
From: rob@bottled.codes ("Rob Landers")

--f70ec8ad9be54116aaa1f9c976687fa8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 on=
ly=20
> > one Scheduler per OS thread. That means creating a new async task do=
es=20
> > not create a new Scheduler.
> >
> > Apparently, async {} in the examples above is the entry point for th=
e=20
> > Scheduler.
> >
>=20
> I've been pondering this, and I think talking about "starting" or=20
> "initialising" the Scheduler is slightly misleading, because it implie=
s=20
> that the Scheduler is something that "happens over there".
>=20
> It sounds like we'd be writing this:
>=20
> // No scheduler running, this is probably an error
> Async\runOnScheduler( something(...) );
>=20
> Async\startScheduler();
> // Great, now it's running...
>=20
> Async\runonScheduler( something(...) );
>=20
> // If we can start it, we can stop it I guess?
> Async\stopScheduler();
>=20
>=20
> But that's not we're talking about. As the RFC says:
>=20
> > Once the Scheduler is activated, it will take control of the=20
> Null-Fiber context, and execution within it will pause until all Fiber=
s,=20
> all microtasks, and all event loop events have been processed.
>=20
> The actual flow in the RFC is like this:
>=20
> // This is queued somewhere special, ready for a scheduler to pick it =
up=20
> later
> Async\enqueueForScheduler( something(...) );
>=20
> // Only now does anything actually run
> Async\runSchedulerUntilQueueEmpty();
> // At this point, the scheduler isn't running any more
>=20
> // If we add to the queue now, it won't run unless we run another sche=
duler
> Async\enqueueForScheduler( something(...) );
>=20
>=20
> Pondering this, I think one of the things we've been missing is what=20
> Unix[-like] systems call "process 0". I'm not an expert, so may get=20
> details wrong, but my understanding is that if you had a single-taskin=
g=20
> OS, and used it to bootstrap a Unix[-like] system, it would look=20
> something like this:
>=20
> 1. You would replace the currently running single process with the new=20
> kernel / scheduler process
> 2. That scheduler would always start with exactly one process in the=20
> queue, traditionally called "init"
> 3. The scheduler would hand control to process 0 (because it's the onl=
y=20
> thing in the queue), and that process would be responsible for startin=
g=20
> all the other processes in the system: TTYs and login prompts, network=20
> 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.

=E2=80=94 Rob
--f70ec8ad9be54116aaa1f9c976687fa8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sun, Mar 9, =
2025, at 14:17, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 08/03/2025 20:22, Edmond Dantes wrot=
e:<br></div><div>&gt;<br></div><div>&gt; For coroutines to work, a Sched=
uler must be started. There can be only&nbsp;<br></div><div>&gt; one Sch=
eduler per OS thread. That means creating a new async task does&nbsp;<br=
></div><div>&gt; not create a new Scheduler.<br></div><div>&gt;<br></div=
><div>&gt; Apparently, async {} in the examples above is the entry point=
 for the&nbsp;<br></div><div>&gt; Scheduler.<br></div><div>&gt;<br></div=
><div><br></div><div>I've been pondering this, and I think talking about=
 "starting" or&nbsp;<br></div><div>"initialising" the Scheduler is sligh=
tly misleading, because it implies&nbsp;<br></div><div>that the Schedule=
r is something that "happens over there".<br></div><div><br></div><div>I=
t sounds like we'd be writing this:<br></div><div><br></div><div>// No s=
cheduler running, this is probably an error<br></div><div>Async\runOnSch=
eduler( something(...) );<br></div><div><br></div><div>Async\startSchedu=
ler();<br></div><div>// Great, now it's running...<br></div><div><br></d=
iv><div>Async\runonScheduler( something(...) );<br></div><div><br></div>=
<div>// If we can start it, we can stop it I guess?<br></div><div>Async\=
stopScheduler();<br></div><div><br></div><div><br></div><div>But that's =
not we're talking about. As the RFC says:<br></div><div><br></div><div>&=
gt; Once the Scheduler is activated, it will take control of the&nbsp;<b=
r></div><div>Null-Fiber context, and execution within it will pause unti=
l all Fibers,&nbsp;<br></div><div>all microtasks, and all event loop eve=
nts have been processed.<br></div><div><br></div><div>The actual flow in=
 the RFC is like this:<br></div><div><br></div><div>// This is queued so=
mewhere special, ready for a scheduler to pick it up&nbsp;<br></div><div=
>later<br></div><div>Async\enqueueForScheduler( something(...) );<br></d=
iv><div><br></div><div>// Only now does anything actually run<br></div><=
div>Async\runSchedulerUntilQueueEmpty();<br></div><div>// At this point,=
 the scheduler isn't running any more<br></div><div><br></div><div>// If=
 we add to the queue now, it won't run unless we run another scheduler<b=
r></div><div>Async\enqueueForScheduler( something(...) );<br></div><div>=
<br></div><div><br></div><div>Pondering this, I think one of the things =
we've been missing is what&nbsp;<br></div><div>Unix[-like] systems call =
"process 0". I'm not an expert, so may get&nbsp;<br></div><div>details w=
rong, but my understanding is that if you had a single-tasking&nbsp;<br>=
</div><div>OS, and used it to bootstrap a Unix[-like] system, it would l=
ook&nbsp;<br></div><div>something like this:<br></div><div><br></div><di=
v>1. You would replace the currently running single process with the new=
&nbsp;<br></div><div>kernel / scheduler process<br></div><div>2. That sc=
heduler would always start with exactly one process in the&nbsp;<br></di=
v><div>queue, traditionally called "init"<br></div><div>3. The scheduler=
 would hand control to process 0 (because it's the only&nbsp;<br></div><=
div>thing in the queue), and that process would be responsible for start=
ing&nbsp;<br></div><div>all the other processes in the system: TTYs and =
login prompts, network&nbsp;<br></div><div>daemons, etc<br></div></block=
quote><div><br></div><div>Slightly off-topic, but you may find the follo=
wing article interesting:&nbsp;<a href=3D"https://manybutfinite.com/post=
/kernel-boot-process/">https://manybutfinite.com/post/kernel-boot-proces=
s/</a><br></div><div><br></div><div>It's a bit old, but probably still r=
elevant for the most part. At least for x86.</div><div><br></div><div id=
=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--f70ec8ad9be54116aaa1f9c976687fa8--