Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129238
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 15 Nov 2025 22:11:21 +0100
To: "John Bafford" <jbafford@zort.net>, "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "php internals" <internals@lists.php.net>,
 "Jakub Zelenka" <bukka@php.net>, "Larry Garfield" <larry@garfieldtech.com>
Message-ID: <0f37fa44-dd56-4773-be33-f1ba57eddcd5@app.fastmail.com>
In-Reply-To: <12D52EE4-62F4-42AC-A17D-A8F3A19D2433@zort.net>
References: 
 <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com>
 <12D52EE4-62F4-42AC-A17D-A8F3A19D2433@zort.net>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
Content-Type: multipart/alternative;
 boundary=4f8127740d9849488015fbfe0f30ce5b
From: rob@bottled.codes ("Rob Landers")

--4f8127740d9849488015fbfe0f30ce5b
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 15, 2025, at 17:20, John Bafford wrote:
> Hi Rob, Edmond,
>=20
> > On Nov 15, 2025, at 06:37, Rob Landers <rob@bottled.codes> wrote:
> >=20
> > I have concerns about the clarity of when suspension occurs in this =
RFC.
> >=20
> > The RFC states as a core goal:
> >=20
> > "Code that was originally written and intended to run outside of a C=
oroutine must work EXACTLY THE SAME inside a Coroutine without modificat=
ions."
> >=20
> > And:
> >=20
> > "A PHP developer should not have to think about how Coroutine switch=
 and should not need to manage their switching=E2=80=94except in special=
 cases where they consciously choose to intervene in this logic."
> >=20
> > [...]
> >=20
> > With explicit async/await ("coloured functions"), developers know ex=
actly where suspension can occur. This RFC=E2=80=99s implicit model seem=
s convenient, but without clear rules about suspension points, I=E2=80=99=
m unclear how developers can write correct concurrent code or reason abo=
ut performance.
> >=20
> > Could the RFC clarify the rules for when automatic suspension occurs=
 versus when manual suspend() calls are required? Is this RFC following =
Go=E2=80=99s model where suspension timing is an implementation detail d=
evelopers shouldn=E2=80=99t rely on? If so, that should be stated explic=
itly. Keep in mind that Go didn=E2=80=99t start that way and took nearly=
 a decade to get there. Earlier versions of Go explicitly stated where s=
uspensions were.
> >=20
> > =E2=80=94 Rob
>=20
> To provide an explicit example for this, code that fits this pattern i=
s going to be problematic:
>=20
> function writeData() {
> $count =3D count($this->data);
> for($x =3D 0; $x < $count; $x++) {
> [$path, $content] =3D $this->data[$x];
> file_put_contents($path, $content);
> }
> $this->data =3D [];
> }
>=20
> While there are better ways to write this function, in normal PHP code=
, there's no problem here. But if file_put_contents() can block and caus=
e a different coroutine to run, $this->data can be changed out from unde=
r writeData(), which leads to unexpected behavior. (e.g. $this->data cha=
nges length, and now writeData() no longer covers all of it; or it runs =
past the end of the array and errors; or doesn't see there's a change an=
d loses it when it clears the data).
>=20
> Now, yes, the programmer would have to do something to cause there to =
be two coroutines running in the first place. But if _this_ code was cor=
rect when "originally written and intended to run outside of a Coroutine=
", and with no changes is incorrect when run inside a coroutine, one can=
 only say that it is working "exactly the same" with coroutines by ignor=
ing that it is now wrong.
>=20
> Suspension points, whether explicit or hidden, allow for the entire re=
st of the world to change out from under the caller. The only way for no=
n-async-aware code to operate safely is for suspension to be explicit (w=
hich, of course, means the code now must be async-aware). There is no wa=
y in general for code written without coroutines or async suspensions in=
 mind to work correctly if it can be suspended.
>=20
> -John

I should have put all these emails combined into a single email ... but =
here we are.

John=E2=80=99s example captures the core issue, and I want to take a mom=
ent and expand on it from a different angle. My concern with implicit su=
spensions isn=E2=80=99t theoretical. It=E2=80=99s exactly why nearly eve=
ry modern language abandoned this model.

Transparent, implicit suspension means that *any* line of code can becom=
e an interleaving point. That makes a large class of patterns, which are=
 perfectly safe in synchronous PHP today, unsafe the moment they run ins=
ide a coroutine. A few concrete examples:

With property hooks and implicit suspension, event this becomes unsafe:

$this->counter++;

A suspension can happen between the read and the write. Another coroutin=
e can mutate the counter in between. The programmer did nothing wrong; i=
t's just a hazard introduced by invisible suspension.

And consider this can break invariants:

$this->balance -=3D $amount;
$this->ledger->writeEntry($this->id, -$amount);

If the first line suspends, the balance can be changed somewhere else be=
fore the ledger entry is written (which breaks an invariant that the bal=
ance is a reflection of the ledger). With transparent async, it's sudden=
ly a race condition.

Then you can have time pass invisibly:

if(!$cache->has($key)) {
  $cache->set($key, $value);
}

If has() suspends, anything can happen to that cache key before the set.=
 The invariant becomes incorrect.

Implicit suspension allows any function to be re-entered before it retur=
ns. That can lead to partially updated objects, state machines appearing=
 to skip states, "method called twice before return" bugs, double writes=
, and re-entrant callbacks being invoked with inconsistent state.

The bugs are extremely challenging to debug because the programmer never=
 actually wrote any async code.

I=E2=80=99ve had the "pleasure" of working on Fiber frameworks that use =
raw fibers (no async/await you get from React/Amp, though I=E2=80=99ve w=
orked with those pretty extensively as well). These are the bugs you run=
 into all the time, where you sometimes have to literally put a suspensi=
on in a seemingly random place to fix a bug.

Implicit async blurs one of the most important boundaries in software de=
sign: "this code cannot be interrupted" vs "this code can be interrupted=
".

- JavaScript moved from implicit async -> promises -> async/await
- Python moved from callbacks/greenlets -> async/await
- Ruby moved from fibers -> explicit schedulers
- Go eventually added true preemption

Even the creators of Fibers eventually wrote async/await on top of them,=
 because implicit async is broken and coloured functions close off entir=
e classes of bugs and make reasoning possible again.

I understand the desire for "transparent async" but once a language allo=
ws suspension at arbitrary points, the language can no longer promise in=
variants, atomic sequences, non-reentrancy, predictable control flow, or=
 even correctness, in-general.

=E2=80=94 Rob
--4f8127740d9849488015fbfe0f30ce5b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sat, Nov =
15, 2025, at 17:20, John Bafford wrote:</div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div>Hi Rob, Edmond,</div><div><br></div><div>&gt; O=
n Nov 15, 2025, at 06:37, Rob Landers &lt;<a href=3D"mailto:rob@bottled.=
codes">rob@bottled.codes</a>&gt; wrote:</div><div>&gt;&nbsp;</div><div>&=
gt; I have concerns about the clarity of when suspension occurs in this =
RFC.</div><div>&gt;&nbsp;</div><div>&gt; The RFC states as a core goal:<=
/div><div>&gt;&nbsp;</div><div>&gt; "Code that was originally written an=
d intended to run outside of a Coroutine must work EXACTLY THE SAME insi=
de a Coroutine without modifications."</div><div>&gt;&nbsp;</div><div>&g=
t; And:</div><div>&gt;&nbsp;</div><div>&gt; "A PHP developer should not =
have to think about how Coroutine switch and should not need to manage t=
heir switching=E2=80=94except in special cases where they consciously ch=
oose to intervene in this logic."</div><div>&gt;&nbsp;</div><div>&gt; [.=
..]</div><div>&gt;&nbsp;</div><div>&gt; With explicit async/await ("colo=
ured functions"), developers know exactly where suspension can occur. Th=
is RFC=E2=80=99s implicit model seems convenient, but without clear rule=
s about suspension points, I=E2=80=99m unclear how developers can write =
correct concurrent code or reason about performance.</div><div>&gt;&nbsp=
;</div><div>&gt; Could the RFC clarify the rules for when automatic susp=
ension occurs versus when manual suspend() calls are required? Is this R=
FC following Go=E2=80=99s model where suspension timing is an implementa=
tion detail developers shouldn=E2=80=99t rely on? If so, that should be =
stated explicitly. Keep in mind that Go didn=E2=80=99t start that way an=
d took nearly a decade to get there. Earlier versions of Go explicitly s=
tated where suspensions were.</div><div>&gt;&nbsp;</div><div>&gt; =E2=80=
=94 Rob</div><div><br></div><div>To provide an explicit example for this=
, code that fits this pattern is going to be problematic:</div><div><br>=
</div><div>function writeData() {</div><div>$count =3D count($this-&gt;d=
ata);</div><div>for($x =3D 0; $x &lt; $count; $x++) {</div><div>[$path, =
$content] =3D $this-&gt;data[$x];</div><div>file_put_contents($path, $co=
ntent);</div><div>}</div><div>$this-&gt;data =3D [];</div><div>}</div><d=
iv><br></div><div>While there are better ways to write this function, in=
 normal PHP code, there's no problem here. But if file_put_contents() ca=
n block and cause a different coroutine to run, $this-&gt;data can be ch=
anged out from under writeData(), which leads to unexpected behavior. (e=
.g. $this-&gt;data changes length, and now writeData() no longer covers =
all of it; or it runs past the end of the array and errors; or doesn't s=
ee there's a change and loses it when it clears the data).</div><div><br=
></div><div>Now, yes, the programmer would have to do something to cause=
 there to be two coroutines running in the first place. But if _this_ co=
de was correct when "originally written and intended to run outside of a=
 Coroutine", and with no changes is incorrect when run inside a coroutin=
e, one can only say that it is working "exactly the same" with coroutine=
s by ignoring that it is now wrong.</div><div><br></div><div>Suspension =
points, whether explicit or hidden, allow for the entire rest of the wor=
ld to change out from under the caller. The only way for non-async-aware=
 code to operate safely is for suspension to be explicit (which, of cour=
se, means the code now must be async-aware). There is no way in general =
for code written without coroutines or async suspensions in mind to work=
 correctly if it can be suspended.</div><div><br></div><div>-John</div><=
/blockquote><div><br></div><div>I should have put all these emails combi=
ned into a single email ... but here we are.</div><div><br></div><div>Jo=
hn=E2=80=99s example captures the core issue, and I want to take a momen=
t and expand on it from a different angle. My concern with implicit susp=
ensions isn=E2=80=99t theoretical. It=E2=80=99s exactly why nearly every=
 modern language abandoned this model.</div><div><br></div><div>Transpar=
ent, implicit suspension means that&nbsp;<b>any</b> line of code can bec=
ome an interleaving point. That makes a large class of patterns, which a=
re perfectly safe in synchronous PHP today, unsafe the moment they run i=
nside a coroutine. A few concrete examples:</div><div><br></div><div>Wit=
h property hooks and implicit suspension, event this becomes unsafe:</di=
v><div><br></div><div>$this-&gt;counter++;</div><div><br></div><div>A su=
spension can happen between the read and the write. Another coroutine ca=
n mutate the counter in between. The programmer did nothing wrong; it's =
just a hazard introduced by invisible suspension.</div><div><br></div><d=
iv>And consider this can break invariants:</div><div><br></div><div>$thi=
s-&gt;balance -=3D $amount;</div><div>$this-&gt;ledger-&gt;writeEntry($t=
his-&gt;id, -$amount);</div><div><br></div><div>If the first line suspen=
ds, the balance can be changed somewhere else before the ledger entry is=
 written (which breaks an invariant that the balance is a reflection of =
the ledger). With transparent async, it's suddenly a race condition.</di=
v><div><br></div><div>Then you can have time pass invisibly:</div><div><=
br></div><div>if(!$cache-&gt;has($key)) {</div><div>&nbsp; $cache-&gt;se=
t($key, $value);</div><div>}</div><div><br></div><div>If has() suspends,=
 anything can happen to that cache key before the set. The invariant bec=
omes incorrect.</div><div><br></div><div>Implicit suspension allows any =
function to be re-entered before it returns. That can lead to partially =
updated objects, state machines appearing to skip states, "method called=
 twice before return" bugs, double writes, and re-entrant callbacks bein=
g invoked with inconsistent state.</div><div><br></div><div>The bugs are=
 extremely challenging to debug because the programmer never actually wr=
ote any async code.</div><div><br></div><div>I=E2=80=99ve had the "pleas=
ure" of working on Fiber frameworks that use raw fibers (no async/await =
you get from React/Amp, though I=E2=80=99ve worked with those pretty ext=
ensively as well). These are the bugs you run into all the time, where y=
ou sometimes have to literally put a suspension in a seemingly random pl=
ace to fix a bug.</div><div><br></div><div>Implicit async blurs one of t=
he most important boundaries in software design: "this code cannot be in=
terrupted" vs "this code can be interrupted".</div><div><br></div><div>-=
 JavaScript moved from implicit async -&gt; promises -&gt; async/await</=
div><div>- Python moved from callbacks/greenlets -&gt; async/await</div>=
<div>- Ruby moved from fibers -&gt; explicit schedulers</div><div>- Go e=
ventually added true preemption</div><div><br></div><div>Even the creato=
rs of Fibers eventually wrote async/await on top of them, because implic=
it async is broken and coloured functions close off entire classes of bu=
gs and make reasoning possible again.</div><div><br></div><div>I underst=
and the desire for "transparent async" but once a language allows suspen=
sion at arbitrary points, the language can no longer promise invariants,=
 atomic sequences, non-reentrancy, predictable control flow, or even cor=
rectness, in-general.</div><div><br></div><div id=3D"sig121229152">=E2=80=
=94 Rob</div></body></html>
--4f8127740d9849488015fbfe0f30ce5b--