Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129239
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <CAMW7n8CeDFSaN0e4Kr=1jrJyHEonHokfxcY4gdf6L3FqdH1FZQ@mail.gmail.com>
 <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> <CAMW7n8AX7O7x99KGdPSai6sPP1Xd6V4ojQ7CEWmxthNLPM2hyQ@mail.gmail.com>
 <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com>
In-Reply-To: <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com>
Date: Sat, 15 Nov 2025 22:17:49 +0100
Message-ID: <CAEKnhAHp9fCOD0NCLE9J25dTkVd72csHGb3HGwATg+qyxNaFwg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: Rob Landers <rob@bottled.codes>
Cc: Edmond Dantes <edmond.ht@gmail.com>, php internals <internals@lists.php.net>, 
	Larry Garfield <larry@garfieldtech.com>
Content-Type: multipart/alternative; boundary="000000000000203f370643a8a652"
From: bukka@php.net (Jakub Zelenka)

--000000000000203f370643a8a652
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sat, Nov 15, 2025 at 8:56=E2=80=AFPM Rob Landers <rob@bottled.codes> wro=
te:

> On Sat, Nov 15, 2025, at 15:41, Edmond Dantes wrote:
>
> Hello.
>
> > Based on the conversation so far, I=E2=80=99d imagine the list to look =
something
> like:
>
> Yes, that=E2=80=99s absolutely correct. When a programmer uses an operati=
on
> that would normally block the entire thread, control is handed over to
> the Scheduler instead.
> The suspend function is called inside all of these operations.
>
>
> I think that "normally" is doing a lot of work here. fwrite() can block,
> but often doesn=E2=80=99t. file_get_contents() is usually instant for loc=
al files
> but can take seconds on NFS or with an HTTP URL. An array_map() *always*
> blocks the thread but should *never* suspend.
>
> Without very clear rules, it becomes impossible to reason about what=E2=
=80=99ll
> suspend and what won=E2=80=99t.
>
>
> > If that=E2=80=99s the intended model, it=E2=80=99d help to have that sp=
elled out
> directly; it makes it immediately clear which functions can or will suspe=
nd
> and prevents surprises.
>
> In the Async implementation, it will be specified which functions are
> supported.
>
>
> This is exactly the kind of thing that needs to be in the RFC itself.
> Relying on "the implementation will document it" creates an unstable
> contract.
>
> Even something simple like:
>
> - if it can perform network IO
> - if it can perform file/stream IO
> - if it can sleep or wait on timers
>

None of the above is part is this RFC so why is this being discussed. Any
of the changes to stream layer and extensions will require special RFC and
mainly clean implementation. We will need to carefully consider where the
suspension is going to be done.

I think if there are parts of the RFC that mention IO, it should be removed
here. I think this RFC should also remove any mention of reactor as it's
irrelevant for this.

Kind regards,

Jakub

--000000000000203f370643a8a652
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><div><br><div class=3D"gmail_quo=
te gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Nov=
 15, 2025 at 8:56=E2=80=AFPM Rob Landers &lt;rob@bottled.codes&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>=
On Sat, Nov 15, 2025, at 15:41, Edmond Dantes wrote:</div><blockquote type=
=3D"cite" id=3D"m_1025473674255130124qt"><div>Hello.</div><div><br></div><d=
iv>&gt; Based on the conversation so far, I=E2=80=99d imagine the list to l=
ook something like:</div><div><br></div><div>Yes, that=E2=80=99s absolutely=
 correct. When a programmer uses an operation</div><div>that would normally=
 block the entire thread, control is handed over to</div><div>the Scheduler=
 instead.</div><div>The suspend function is called inside all of these oper=
ations.</div></blockquote><div><br></div><div>I think that &quot;normally&q=
uot; is doing a lot of work here. <code style=3D"border-width:1px;border-st=
yle:solid;border-color:rgb(204,204,204);border-radius:3px;background-image:=
initial;background-size:initial;background-repeat:initial;background-origin=
:initial;background-clip:initial;background-color:rgb(246,246,246);font-fam=
ily:menlo,consolas,monospace;font-size:90%;padding:1px 3px">fwrite()</code>=
 can block, but often doesn=E2=80=99t. <code style=3D"border-width:1px;bord=
er-style:solid;border-color:rgb(204,204,204);border-radius:3px;background-i=
mage:initial;background-size:initial;background-repeat:initial;background-o=
rigin:initial;background-clip:initial;background-color:rgb(246,246,246);fon=
t-family:menlo,consolas,monospace;font-size:90%;padding:1px 3px">file_get_c=
ontents()</code> is usually instant for local files but can take seconds on=
 NFS or with an HTTP URL. An <code style=3D"border-width:1px;border-style:s=
olid;border-color:rgb(204,204,204);border-radius:3px;background-image:initi=
al;background-size:initial;background-repeat:initial;background-origin:init=
ial;background-clip:initial;background-color:rgb(246,246,246);font-family:m=
enlo,consolas,monospace;font-size:90%;padding:1px 3px">array_map()</code> <=
b>always</b> blocks the thread but should <b>never</b> suspend.</div><div><=
br></div><div>Without very clear rules, it becomes impossible to reason abo=
ut what=E2=80=99ll suspend and what won=E2=80=99t.</div><div><br></div><blo=
ckquote type=3D"cite" id=3D"m_1025473674255130124qt"><div><br></div><div>&g=
t; If that=E2=80=99s the intended model, it=E2=80=99d help to have that spe=
lled out directly; it makes it immediately clear which functions can or wil=
l suspend and prevents surprises.</div><div><br></div><div>In the Async imp=
lementation, it will be specified which functions are supported.</div></blo=
ckquote><div><br></div><div>This is exactly the kind of thing that needs to=
 be in the RFC itself. Relying on &quot;the implementation will document it=
&quot; creates an unstable contract.</div><div><br></div><div>Even somethin=
g simple like:</div><div><br></div><div>- if it can perform network IO</div=
><div>- if it can perform file/stream IO</div><div>- if it can sleep or wai=
t on timers</div></div></blockquote><div><br></div><div>None of the above i=
s part is this RFC so why is this being discussed. Any of the changes to st=
ream layer and extensions will require special RFC and mainly clean impleme=
ntation. We will need to carefully consider where the suspension is going t=
o be done.</div><div><br></div><div>I think if there are parts of the RFC t=
hat mention IO, it should be removed here. I think this RFC should also rem=
ove any mention of reactor as it&#39;s irrelevant for this.</div><div><br><=
/div><div>Kind regards,</div><div><br></div><div>Jakub=C2=A0</div></div></d=
iv></div>

--000000000000203f370643a8a652--