Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126669
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com> <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com> <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk>
 <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com> <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
 <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com> <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com>
 <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com> <D73BCCC4-3547-45B4-84AD-A5FD6569D43C@rwec.co.uk>
 <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com> <9b7ab30f-5ed6-400d-b941-1291e9185286@app.fastmail.com>
 <9a2e81e8-3534-455b-879a-5a45c85b3ba7@gmail.com> <CAMW7n8BRwZH64mULctRS4CxOL9TCo5GHvz-ORWHMZr926ZujYw@mail.gmail.com>
 <CAAwdEzALuRtkWyw1JgRVVmU9ew8uTiY6DSruR2CKiqNQ03QzOw@mail.gmail.com> <CAMW7n8A17ER8vUkNNrEsbkyGm2xY-ZAxkR1_ofWcHmgFbNrzqg@mail.gmail.com>
In-Reply-To: <CAMW7n8A17ER8vUkNNrEsbkyGm2xY-ZAxkR1_ofWcHmgFbNrzqg@mail.gmail.com>
Date: Sun, 9 Mar 2025 10:04:14 +0100
Message-ID: <CAAwdEzBU2pttT5s8DFN1hfB-gS8-HKsAfDowuAj0BKaX007hDQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Daniil Gentili <daniil.gentili@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005d3bdb062fe524b4"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000005d3bdb062fe524b4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 9, 2025, 09:05 Edmond Dantes <edmond.ht@gmail.com> wrote:

> When a *Fiber* from the *Scheduler* decides to create another *Fiber* and
> then tries to call blocking functions inside it, control can no longer
> return to the *Scheduler* from those functions.
>
> Of course, it would be possible to track the state and disable the
> concurrency mode flag when the user manually creates a *Fiber*. But=E2=80=
=A6 this
> wouldn't lead to anything good. Not only would it complicate the code, bu=
t
> it would also result in a mess with different behavior inside and outside
> of *Fiber*.
>
>
Thank you for explaining the problem space.
Now let's see what solutions we can find.

First of all, I think it would be better for the language to assume the
Scheduler is always running and not have to be manually started.

An idea that I have for now:
Have a different method `Fiber::suspendToScheduler(Resume $resume)` that
would return the control to the Scheduler. And this one would be used by
all internal functions that does blocking operations, and maybe also user
land ones if they need to. Of course, the name can be better, like
`Fiber::await`.

Maybe that is what we need: to be able to return control both to the parent
fiber for custom logic that might be needed, and to the Scheduler so that
the language would be concurrent.

As for userland event loops, like Revolt, I am not so sure they fit with
the new language level async model.
But I can see how they could implement a different Event loop that would
run only one "loop", schedule a deffered callback and pass control to the
Scheduler (that would return the control in the next iteration to perform
one more loop, and so on.

--=20
Alex

>

--0000000000005d3bdb062fe524b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><br><div class=3D"gmail_quote gmail_quote_container" =
dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 9, 2025, 09:=
05 Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond.ht@gmail=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><p>When a <strong>Fiber</strong> from the <strong>Scheduler</strong>=
 decides to create another <strong>Fiber</strong> and then tries to call bl=
ocking functions inside it, control can no longer return to the <strong>Sch=
eduler</strong> from those functions.</p><p>Of course, it would be possible=
 to track the state and disable the concurrency mode flag when the user man=
ually creates a <strong>Fiber</strong>. But=E2=80=A6 this wouldn&#39;t lead=
 to anything good. Not only would it complicate the code, but it would also=
 result in a mess with different behavior inside and outside of <strong>Fib=
er</strong>.</p><p>

</p><p></p></div></div></blockquote></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Thank you for explaining the problem space.</div><div dir=3D"a=
uto">Now let&#39;s see what solutions we can find.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">First of all, I think it would be better for the=
 language to assume the Scheduler is always running and not have to be manu=
ally started.</div><div dir=3D"auto"><br></div><div dir=3D"auto">An idea th=
at I have for now:</div><div dir=3D"auto">Have a different method `Fiber::s=
uspendToScheduler(Resume $resume)` that would return the control to the Sch=
eduler. And this one would be used by all internal functions that does bloc=
king operations, and maybe also user land ones if they need to. Of course, =
the name can be better, like `Fiber::await`.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Maybe that is what we need: to be able to return contr=
ol both to the parent fiber for custom logic that might be needed, and to t=
he Scheduler so that the language would be concurrent.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">As for userland event loops, like Revolt, I =
am not so sure they fit with the new language level async model.</div><div =
dir=3D"auto">But I can see how they could implement a different Event loop =
that would run only one &quot;loop&quot;, schedule a deffered callback and =
pass control to the Scheduler (that would return the control in the next it=
eration to perform one more loop, and so on.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">--=C2=A0</div><div dir=3D"auto">Alex</div><div class=
=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><p></p></div></div>
</blockquote></div></div>

--0000000000005d3bdb062fe524b4--