Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126631
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 08 Mar 2025 08:38:44 +0100
To: internals@lists.php.net
Message-ID: <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com>
In-Reply-To: <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
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>
Subject: Re: [PHP-DEV] PHP True Async RFC
Content-Type: multipart/alternative;
 boundary=67b9960310a2415289787b3f6c8cf949
From: rob@bottled.codes ("Rob Landers")

--67b9960310a2415289787b3f6c8cf949
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Mar 8, 2025, at 00:21, Rowan Tommins [IMSoP] wrote:
> On 07/03/2025 22:01, Larry Garfield wrote:
> > Is that what you're suggesting?  If so, I'd have to think it through=
 a bit more to see what guarantees that does[n't] provide.  It might wor=
k.  (I deliberately used spawn instead of "await" to avoid the mental as=
sociation with JS async/await.)  My biggest issue is that this is starti=
ng to feel like colored functions, even if partially transparent.
>=20
>=20
> Yes, that's pretty much what was in my head. I freely admit I haven't=20
> thought through the implications either.
>=20
>=20
> > My biggest issue is that this is starting to feel like colored funct=
ions, even if partially transparent.
>=20
>=20
> I think it's significantly *less* like coloured functions than passing=20
> around a nursery object. You could almost take this:
>=20
> async function foo($bar int, $baz string) {
>     spawn something_else();
> }
> spawn foo(42, 'hello');
>=20
> As sugar for this:
>=20
> function foo($bar int, $baz string, AsyncNursery $__nursery) {
>     $__nursery->spawn( something_else(...) );
> }
> $__nursery->spawn( fn($n) =3D> foo(42, 'hello', $n) );
>=20
> However you spell it, you've had to change the function's *signature* =
in=20
> order to use async facilities in its *body*.
>=20
>=20
> If the body can say "get current nursery", it can be called even if it=
s=20
> *immediate* caller has no knowledge of async code, as long as we have=20
> some reasonable definition of "current".
>=20
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20

The uncoloring of functions in PHP is probably one of the most annoying =
aspects of fibers, IMHO. It's hard to explain unless you've been using t=
hem awhile. But, with colored functions, the caller has control over whe=
n the result is waiting on -- it could be now, it could be in a totally =
different part of the program, or not at all. With fibers, the author of=
 the function you are calling has control over when the result is waited=
 on (and they don't have control over anything they call). This can crea=
te unpredictable issues when writing code where a specific part wrote so=
me code thinking it had exclusive access to a property/variable. However=
, someone else changed one of the functions being called into an async f=
unction, making that assumption no longer true.

With colored functions, the person making changes also has to update all=
 the places where it is called and can validate any assumptions are stil=
l going to be true; uncolored functions means they almost never do this.=
 This results in more work for people implementing async, but more corre=
ct programs overall.

But back to the awaiting on results. Say I want to read 10 files:

for ($i =3D 0; $i < 10; $i++) $results[] =3D file_get_contents($file[$i]=
);

Right now, we have to read each file, one at a time, because this is syn=
chronous. Even with this RFC and being in a fiber, the overall execution=
 might be non-blocking, but the code still reads one file after another =
sequentially. Fibers do not change this.

With this RFC (in its original form), we will be able to change it so th=
at we can run it asynchronously though and choose when to wait:

for($i =3D 0; $i < 10; $i++) $results[] =3D async\async(fn($f) =3D> file=
_get_contents($f), $file[$i]);
// convert $results into futures somehow -- though actually doesn't look=
 like it is possible.
$results =3D async\awaitAll($results);

In that example, we are deliberately starting to read all 10 files at th=
e same time. If we had colored functions (aka, async/await) then changin=
g file_get_contents to async would mean you have to change everywhere it=
 is called too. That means I would see that file_get_contents is synchro=
nous and be able to optimize it without having to even understand the re=
asoning (in most cases). I was a user of C# when this happened to C#, an=
d it was a pain... So, at least with PHP fibers, this won't be AS painfu=
l, but you still have to do some work to take full advantage of them.

I kind of like the idea of a nursery for async, as we could then update =
file_get_content's return type to something like string|false|future<str=
ing|false>. In non-async, you have everything behave as normal, but insi=
de a nursery, it returns a future that can be awaited however you want a=
nd is fully non-blocking. In other words, simply returning a future is e=
nough for the engine to realize it should spawn a fiber (similar to how =
using yield works with generators).=20

In any case, I believe that a nursery requires the use of colored functi=
ons. That may be good or bad, but IMHO makes it much more useful and eas=
ier to write correct and fast code.

=E2=80=94 Rob
--67b9960310a2415289787b3f6c8cf949
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><br></div><div>=
<br></div><div>On Sat, Mar 8, 2025, at 00:21, Rowan Tommins [IMSoP] wrot=
e:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 07/03=
/2025 22:01, Larry Garfield wrote:<br></div><div>&gt; Is that what you'r=
e suggesting?&nbsp; If so, I'd have to think it through a bit more to se=
e what guarantees that does[n't] provide.&nbsp; It might work.&nbsp; (I =
deliberately used spawn instead of "await" to avoid the mental associati=
on with JS async/await.)&nbsp; My biggest issue is that this is starting=
 to feel like colored functions, even if partially transparent.<br></div=
><div><br></div><div><br></div><div>Yes, that's pretty much what was in =
my head. I freely admit I haven't&nbsp;<br></div><div>thought through th=
e implications either.<br></div><div><br></div><div><br></div><div>&gt; =
My biggest issue is that this is starting to feel like colored functions=
, even if partially transparent.<br></div><div><br></div><div><br></div>=
<div>I think it's significantly *less* like coloured functions than pass=
ing&nbsp;<br></div><div>around a nursery object. You could almost take t=
his:<br></div><div><br></div><div>async function foo($bar int, $baz stri=
ng) {<br></div><div>&nbsp;&nbsp;&nbsp; spawn something_else();<br></div>=
<div>}<br></div><div>spawn foo(42, 'hello');<br></div><div><br></div><di=
v>As sugar for this:<br></div><div><br></div><div>function foo($bar int,=
 $baz string, AsyncNursery $__nursery) {<br></div><div>&nbsp;&nbsp;&nbsp=
; $__nursery-&gt;spawn( something_else(...) );<br></div><div>}<br></div>=
<div>$__nursery-&gt;spawn( fn($n) =3D&gt; foo(42, 'hello', $n) );<br></d=
iv><div><br></div><div>However you spell it, you've had to change the fu=
nction's *signature* in&nbsp;<br></div><div>order to use async facilitie=
s in its *body*.<br></div><div><br></div><div><br></div><div>If the body=
 can say "get current nursery", it can be called even if its&nbsp;<br></=
div><div>*immediate* caller has no knowledge of async code, as long as w=
e have&nbsp;<br></div><div>some reasonable definition of "current".<br><=
/div><div><br></div><div><br></div><div>--&nbsp;<br></div><div>Rowan Tom=
mins<br></div><div>[IMSoP]<br></div><div><br></div></blockquote><div><br=
></div><div>The uncoloring of functions in PHP is probably one of the mo=
st annoying aspects of fibers, IMHO. It's hard to explain unless you've =
been using them awhile. But, with colored functions, the caller has cont=
rol over when the result is waiting on -- it could be now, it could be i=
n a totally different part of the program, or not at all. With fibers, t=
he author of the function you are calling has control over when the resu=
lt is waited on (and they don't have control over anything they call). T=
his can create unpredictable issues when writing code where a specific p=
art wrote some code thinking it had exclusive access to a property/varia=
ble. However, someone else changed one of the functions being called int=
o an async function, making that assumption no longer true.<br></div><di=
v><br></div><div>With colored functions, the person making changes also =
has to update all the places where it is called and can validate any ass=
umptions are still going to be true; uncolored functions means they almo=
st never do this. This results in more work for people implementing asyn=
c, but more correct programs overall.<br></div><div><br></div><div>But b=
ack to the awaiting on results. Say I want to read 10 files:<br></div><d=
iv><br></div><div>for ($i =3D 0; $i &lt; 10; $i++) $results[] =3D file_g=
et_contents($file[$i]);<br></div><div><br></div><div>Right now, we have =
to read each file, one at a time, because this is synchronous. Even with=
 this RFC and being in a fiber, the overall execution might be non-block=
ing, but the code still reads one file after another sequentially. Fiber=
s do not change this.<br></div><div><br></div><div>With this RFC (in its=
 original form), we will be able to change it so that we can run it asyn=
chronously though and choose when to wait:<br></div><div><br></div><div>=
for($i =3D 0; $i &lt; 10; $i++) $results[] =3D async\async(fn($f) =3D&gt=
; file_get_contents($f), $file[$i]);<br></div><div>// convert $results i=
nto futures somehow -- though actually doesn't look like it is possible.=
<br></div><div>$results =3D async\awaitAll($results);<br></div><div><br>=
</div><div>In that example, we are deliberately starting to read all 10 =
files at the same time. If we had colored functions (aka, async/await) t=
hen changing file_get_contents to async would mean you have to change ev=
erywhere it is called too. That means I would see that file_get_contents=
 is synchronous and be able to optimize it without having to even unders=
tand the reasoning (in most cases). I was a user of C# when this happene=
d to C#, and it was a pain... So, at least with PHP fibers, this won't b=
e AS painful, but you still have to do some work to take full advantage =
of them.<br></div><div><br></div><div>I kind of like the idea of a nurse=
ry for async, as we could then update file_get_content's return type to =
something like string|false|future&lt;string|false&gt;. In non-async, yo=
u have everything behave as normal, but inside a nursery, it returns a f=
uture that can be awaited however you want and is fully non-blocking. In=
 other words, simply returning a future is enough for the engine to real=
ize it should spawn a fiber (similar to how using yield works with gener=
ators).&nbsp;<br></div><div><br></div><div>In any case, I believe that a=
 nursery requires the use of colored functions. That may be good or bad,=
 but IMHO makes it much more useful and easier to write correct and fast=
 code.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></d=
iv></body></html>
--67b9960310a2415289787b3f6c8cf949--