Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126423
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 16 Feb 2025 12:40:41 +0100
To: internals@lists.php.net
Message-ID: <ccd08640-b873-4a22-94f3-ce8ef47bdbe8@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8D5kEB88qJiV8dx5fP9KGbaUa6Xc9znjqYcNOjG4oiXBQ@mail.gmail.com>
References: 
 <CAMW7n8CcNuttyxhtDeG1apHFVjU_9sKAhf0RG890b82Q1AnJpw@mail.gmail.com>
 <CAEKnhAFX-RnmRwgP_OoMs_fV2J_NWrfbEvUMDqMwgp_Td4JrOQ@mail.gmail.com>
 <CAMW7n8AC_VAg0eOZFBorma2jFX=5eS0TCSOP2sY67Dz6BiQyjQ@mail.gmail.com>
 <CAMW7n8D5kEB88qJiV8dx5fP9KGbaUa6Xc9znjqYcNOjG4oiXBQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async
Content-Type: multipart/alternative;
 boundary=c210af0d81154495a43565570cc87223
From: rob@bottled.codes ("Rob Landers")

--c210af0d81154495a43565570cc87223
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 14, 2025, at 15:16, Edmond Dantes wrote:
> Hello, *Jakub.*
> (It seems that simply clicking "Reply" does not work for the conferenc=
e)
> **
> *> *I understand that's not ready for review yet but quickly
>   You could say that the code is in a state of "architectural stabilit=
y," so it can be reviewed and criticized. (Unfortunately, only the Windo=
ws build is currently working.)=20
> In the near future, I plan to start documenting the C-API, where I wil=
l describe the implementation details in depth, but feel free to ask any=
 questions about this component. =20
>=20
> Link: https://github.com/EdmondDantes/php-src/tree/async/async
>=20

Just looking through the PHP stubs, and here are some notes:

Channels:
- It is probably best to have channels be non-buffered by default (like =
in Go); buffered channels can hide architectural issues in async code.
- Why do we need "finishing" producing and consuming? Won't "closing" th=
e channel be enough, or does closing a channel prevent consumers from re=
ading pending items? Personally, it should be an exception (or at least =
a warning) if a channel gets GC'd with pending data.
- Looking at the public api, it seems that it is very hard to use correc=
tly. It would probably be a good idea to pair it down and come up with a=
n api/ideomatic usage that makes it hard to use incorrectly.

Callback:
- Can we name this Async\Closure or something similar? Just to keep it i=
nline with the current \Closure
- Speaking of, you probably meant to use \Closure as the $callback prope=
rty instead of mixed?

Futures:
- The constructor for a Future is public, but it looks like it would be =
weird to use.

Module:
- It would be nice to see this simply use Futures as much as possible. F=
or example, returning a Future instead of FiberHandles.
- Is onSignal OS signals or application signals? (I didn't look at the C=
 code) If the latter, it is probably better to use something other than =
integer. If the former, this is usually handled by extensions (such as p=
cntl) and comes with a ton of caveats. It might be better to let those e=
xtensions handle that.

Notifier:
- Exposing $reserved -- which is accessible via reflection -- is probabl=
y a bad idea.
- Should this be implementing Stringable interface? Also, this will auto=
matically cast to a string if accidentally passed to a function that tak=
es a string -- unless you are using strict mode. https://3v4l.org/3AqcW =
This is probably not desired.
- Instead of Terminate(), should it be Close(), to be consistent with th=
e rest of the library?
- It would be nice to get a list of callbacks on the Notifier as well.

Walker:
- It would be nice to be able to get a future from the Walker instead of=
 polling "isFinished".
- IMHO, it would be better to implement this around Futures (see amphp's=
 extensive library around this). Here are some examples from my own code:

- timeouts: race two futures, one which times out and the other which pe=
rforms a long-running task. If the timeout wins, then I cancel the long-=
running task and proceed as an error. If the long-running task wins, I c=
ancel the timeout.

- wait for all to complete: there are a couple of variations on this the=
me. But sometimes we want to wait for all to complete, errors or not; so=
metimes we want to stop on the first error; and sometimes we want to jus=
t get the first success (see timeouts).

All in all, this is a good start. It would probably be a good idea to ta=
ke a deeper look at other Channel implementations and borrow heavily fro=
m them. The current implementation seems to leak a lot of internal infor=
mation that most programs should not use. As a producer, all I care abou=
t is that the channel is open; not that anyone is listening or not. Ther=
e may be nobody listening right now; but because it is async, it is my j=
ob as a programmer to make sure that someone is listening, eventually. S=
ame with consumers, they don't need to know whether someone is actually =
producing, just that the channel is open so they can consume. It may be =
a good idea to create a way to use it with match:

$result =3D match (Async\select($channel)) {
  Async\EOF =3D> "channel closed",
  default =3D> $channel->receive(),
}

Where Async\select() just pauses until there is a value and returns "nul=
l" or "EOF" or something when it has a value available or becomes closed=
. Also, keep in mind this is pretty valid:

$channel->send($data);
$channel->close();

A consumer should read $data before seeing the channel as closed. I pres=
ume that this is what "finishProducing()" is for, but it requires synchr=
onization to work properly and the entire idea of channels is to not nee=
d synchronization at all.

=E2=80=94 Rob
--c210af0d81154495a43565570cc87223
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 Fri, Feb 14,=
 2025, at 15:16, Edmond Dantes wrote:<br></div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"=
><div>Hello,&nbsp;<span style=3D"color:rgb(31, 31, 31);"><span class=3D"=
font" style=3D"font-family:&quot;Google Sans&quot;, Roboto, RobotoDraft,=
 Helvetica, Arial, sans-serif;"><span class=3D"size" style=3D"font-size:=
0.875rem;"><b>Jakub.</b><br>(</span></span></span>It seems that simply c=
licking "Reply" does not work for the conference<span style=3D"color:rgb=
(31, 31, 31);"><span class=3D"font" style=3D"font-family:&quot;Google Sa=
ns&quot;, Roboto, RobotoDraft, Helvetica, Arial, sans-serif;"><span clas=
s=3D"size" style=3D"font-size:0.875rem;">)</span></span></span></div><sp=
an class=3D"qt-gmail-im" style=3D"color:rgb(80, 0, 80);"><div><span styl=
e=3D"color:rgb(31, 31, 31);"><b><span class=3D"font" style=3D"font-famil=
y:&quot;Google Sans&quot;, Roboto, RobotoDraft, Helvetica, Arial, sans-s=
erif;"><span class=3D"size" style=3D"font-size:0.875rem;"></span></span>=
</b></span><br></div><div><span class=3D"font" style=3D"font-family:&quo=
t;Google Sans&quot;, Roboto, RobotoDraft, Helvetica, Arial, sans-serif;"=
><span class=3D"color" style=3D"color:rgb(31, 31, 31);"><span class=3D"s=
ize" style=3D"font-size:14px;"><b>&gt;&nbsp;</b></span></span></span>I u=
nderstand that's not ready for review yet but quickly<br></div></span><d=
iv>&nbsp; You could say that the code is in a state of "architectural st=
ability," so it can be reviewed and criticized. (Unfortunately, only the=
 Windows build is currently working.)&nbsp;<br></div><div>In the near fu=
ture, I plan to start documenting the C-API, where I will describe the i=
mplementation details in depth, but feel free to ask any questions about=
 this component.&nbsp;&nbsp;<br></div><div><br></div><div>Link:&nbsp;<a =
href=3D"https://github.com/EdmondDantes/php-src/tree/async/async" target=
=3D"_blank">https://github.com/EdmondDantes/php-src/tree/async/async</a>=
<br></div><span class=3D"qt-gmail-im" style=3D"color:rgb(80, 0, 80);"><d=
iv><br></div></span></div></div></div></blockquote><div><br></div><div>J=
ust looking through the PHP stubs, and here are some notes:<br></div><di=
v><br></div><div>Channels:<br></div><div>- It is probably best to have c=
hannels be non-buffered by default (like in Go); buffered channels can h=
ide architectural issues in async code.<br></div><div>- Why do we need "=
finishing" producing and consuming? Won't "closing" the channel be enoug=
h, or does closing a channel prevent consumers from reading pending item=
s? Personally, it should be an exception (or at least a warning) if a ch=
annel gets GC'd with pending data.<br></div><div>- Looking at the public=
 api, it seems that it is very hard to use correctly. It would probably =
be a good idea to pair it down and come up with an api/ideomatic usage t=
hat makes it hard to use incorrectly.<br></div><div><br></div><div>Callb=
ack:<br></div><div>- Can we name this Async\Closure or something similar=
? Just to keep it inline with the current \Closure<br></div><div>- Speak=
ing of, you probably meant to use \Closure as the $callback property ins=
tead of mixed?<br></div><div><br></div><div>Futures:<br></div><div>- The=
 constructor for a Future is public, but it looks like it would be weird=
 to use.<br></div><div><br></div><div>Module:<br></div><div>- It would b=
e nice to see this simply use Futures as much as possible. For example, =
returning a Future instead of FiberHandles.<br></div><div>- Is onSignal =
OS signals or application signals? (I didn't look at the C code) If the =
latter, it is probably better to use something other than integer. If th=
e former, this is usually handled by extensions (such as pcntl) and come=
s with a ton of caveats. It might be better to let those extensions hand=
le that.<br></div><div><br></div><div>Notifier:<br></div><div>- Exposing=
 $reserved -- which is accessible via reflection -- is probably a bad id=
ea.<br></div><div>- Should this be implementing Stringable interface? Al=
so, this will automatically cast to a string if accidentally passed to a=
 function that takes a string -- unless you are using strict mode.&nbsp;=
<a href=3D"https://3v4l.org/3AqcW">https://3v4l.org/3AqcW</a>&nbsp;This =
is probably not desired.<br></div><div>- Instead of Terminate(), should =
it be Close(), to be consistent with the rest of the library?<br></div><=
div>- It would be nice to get a list of callbacks on the Notifier as wel=
l.<br></div><div><br></div><div>Walker:<br></div><div>- It would be nice=
 to be able to get a future from the Walker instead of polling "isFinish=
ed".<br></div><div>- IMHO, it would be better to implement this around F=
utures (see amphp's extensive library around this). Here are some exampl=
es from my own code:<br></div><div><br></div><div>- timeouts: race two f=
utures, one which times out and the other which performs a long-running =
task. If the timeout wins, then I cancel the long-running task and proce=
ed as an error. If the long-running task wins, I cancel the timeout.<br>=
</div><div><br></div><div>- wait for all to complete: there are a couple=
 of variations on this theme. But sometimes we want to wait for all to c=
omplete, errors or not; sometimes we want to stop on the first error; an=
d sometimes we want to just get the first success (see timeouts).<br></d=
iv><div><br></div><div>All in all, this is a good start. It would probab=
ly be a good idea to take a deeper look at other Channel implementations=
 and borrow heavily from them. The current implementation seems to leak =
a lot of internal information that most programs should not use. As a pr=
oducer, all I care about is that the channel is open; not that anyone is=
 listening or not. There may be nobody listening right now; but because =
it is async, it is my job as a programmer to make sure that someone is l=
istening, eventually. Same with consumers, they don't need to know wheth=
er someone is actually producing, just that the channel is open so they =
can consume. It may be a good idea to create a way to use it with match:=
<br></div><div><br></div><div>$result =3D match (Async\select($channel))=
 {<br></div><div>&nbsp; Async\EOF =3D&gt; "channel closed",<br></div><di=
v>&nbsp; default =3D&gt; $channel-&gt;receive(),<br></div><div>}<br></di=
v><div><br></div><div>Where Async\select() just pauses until there is a =
value and returns "null" or "EOF" or something when it has a value avail=
able or becomes closed. Also, keep in mind this is pretty valid:<br></di=
v><div><br></div><div>$channel-&gt;send($data);<br></div><div>$channel-&=
gt;close();<br></div><div><br></div><div>A consumer should read $data be=
fore seeing the channel as closed. I presume that this is what "finishPr=
oducing()" is for, but it requires synchronization to work properly and =
the entire idea of channels is to not need synchronization at all.<br></=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></bod=
y></html>
--c210af0d81154495a43565570cc87223--