Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126633
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>
In-Reply-To: <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com>
Date: Sat, 8 Mar 2025 10:06:02 +0200
Message-ID: <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Rob Landers <rob@bottled.codes>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000075cefc062fd03624"
From: zsidelnik@gmail.com (Eugene Sidelnyk)

--00000000000075cefc062fd03624
Content-Type: text/plain; charset="UTF-8"

>
>
>
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 them
> awhile. But, with colored functions, the caller has control over when 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 create unpredictable
> issues when writing code where a specific part wrote some code thinking it
> had exclusive access to a property/variable. However, someone else changed
> one of the functions being called into an async function, 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 still
> going to be true; uncolored functions means they almost never do this. This
> results in more work for people implementing async, but more correct
> programs overall.
>
> But back to the awaiting on results. Say I want to read 10 files:
>
> for ($i = 0; $i < 10; $i++) $results[] = file_get_contents($file[$i]);
>
> 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-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 that
> we can run it asynchronously though and choose when to wait:
>
> for($i = 0; $i < 10; $i++) $results[] = async\async(fn($f) =>
> file_get_contents($f), $file[$i]);
> // convert $results into futures somehow -- though actually doesn't look
> like it is possible.
> $results = async\awaitAll($results);
>
> In that example, we are deliberately starting to read all 10 files at the
> same time. If we had colored functions (aka, async/await) then changing
> 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 synchronous
> and be able to optimize it without having to even understand the reasoning
> (in most cases). I was a user of C# when this happened to C#, and it was a
> pain... So, at least with PHP fibers, this won't be AS painful, 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<string|false>. In non-async, you have everything behave
> as normal, but inside a nursery, it returns a future 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 realize it should spawn a
> fiber (similar to how using yield works with generators).
>
> 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.
>


In my opinion, colored functions is the worst thing that could happen to
PHP.

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function
Describes quite expressively what's wrong about this approach.

As the result, you will make everything async.
Want a repository? It will be all async.
Want a logger? Also async.
Need to cache something? Make it async.

This is going to be a ton of changes, when currently sync (blue function)
will have to become async (red one).

The way amphp goes - it's the right way. They have had this problem of
red-blue functions a long ago until Fibers came into place.

What they used until third version is generator-based coroutines, so that
instead of returning actual object, you spoil the signature of the function
and return generator that will return that object (iow, "Promise").

This is just annoying, and IMO should not be considered.

--00000000000075cefc062fd03624
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><br></blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div><div>The uncoloring of functions in P=
HP is probably one of the most annoying aspects of fibers, IMHO. It&#39;s h=
ard to explain unless you&#39;ve been using them awhile. But, with colored =
functions, the caller has control over when the result is waiting on -- it =
could be now, it could be in a totally different part of the program, or no=
t at all. With fibers, the author of the function you are calling has contr=
ol over when the result is waited on (and they don&#39;t have control over =
anything they call). This can create unpredictable issues when writing code=
 where a specific part wrote some code thinking it had exclusive access to =
a property/variable. However, someone else changed one of the functions bei=
ng called into an async function, making that assumption no longer true.<br=
></div><div><br></div><div>With colored functions, the person making change=
s also has to update all the places where it is called and can validate any=
 assumptions are still going to be true; uncolored functions means they alm=
ost never do this. This results in more work for people implementing async,=
 but more correct programs overall.<br></div><div><br></div><div>But back t=
o the awaiting on results. Say I want to read 10 files:<br></div><div><br><=
/div><div>for ($i =3D 0; $i &lt; 10; $i++) $results[] =3D file_get_contents=
($file[$i]);<br></div><div><br></div><div>Right now, we have to read each f=
ile, one at a time, because this is synchronous. Even with this RFC and bei=
ng in a fiber, the overall execution might be non-blocking, but the code st=
ill reads one file after another sequentially. Fibers do not change this.<b=
r></div><div><br></div><div>With this RFC (in its original form), we will b=
e able to change it so that we can run it asynchronously 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 into futures somehow -- though actually=
 doesn&#39;t look like it is possible.<br></div><div>$results =3D async\awa=
itAll($results);<br></div><div><br></div><div>In that example, we are delib=
erately starting to read all 10 files at the same time. If we had colored f=
unctions (aka, async/await) then changing 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 synchronous and be able to optimize it without h=
aving to even understand the reasoning (in most cases). I was a user of C# =
when this happened to C#, and it was a pain... So, at least with PHP fibers=
, this won&#39;t be 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 ide=
a of a nursery for async, as we could then update file_get_content&#39;s re=
turn type to something like string|false|future&lt;string|false&gt;. In non=
-async, you have everything behave as normal, but inside a nursery, it retu=
rns a future 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 rea=
lize it should spawn a fiber (similar to how using yield works with generat=
ors).=C2=A0<br></div><div><br></div><div>In any case, I believe that a nurs=
ery requires the use of colored functions. That may be good or bad, but IMH=
O makes it much more useful and easier to write correct and fast code.</div=
><div></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">In my opinion, colored functions =
is the worst thing that could happen to PHP.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto"><a href=3D"https://journal.stuffwithstuff.com/2015/02/=
01/what-color-is-your-function">https://journal.stuffwithstuff.com/2015/02/=
01/what-color-is-your-function</a></div><div dir=3D"auto">Describes quite e=
xpressively what&#39;s wrong about this approach.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">As the result, you will make everything async.</d=
iv><div dir=3D"auto">Want a repository? It will be all async.</div><div dir=
=3D"auto">Want a logger? Also async.</div><div dir=3D"auto">Need to cache s=
omething? Make it async.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>This is going to be a ton of changes, when currently sync (blue function) =
will have to become async (red one).</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">The way amphp goes - it&#39;s the right way. They have had thi=
s problem of red-blue functions a long ago until Fibers came into place.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">What they used until third=
 version is generator-based coroutines, so that instead of returning actual=
 object, you spoil the signature of the function and return generator that =
will return that object (iow, &quot;Promise&quot;).</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">This is just annoying, and IMO should not be co=
nsidered.</div></div>

--00000000000075cefc062fd03624--