Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129237
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 15 Nov 2025 21:29:40 +0100
To: "Edmond Dantes" <edmond.ht@gmail.com>, "John Bafford" <jbafford@zort.net>
Cc: "php internals" <internals@lists.php.net>,
 "Jakub Zelenka" <bukka@php.net>, "Larry Garfield" <larry@garfieldtech.com>
Message-ID: <c9250a28-30ff-4e4f-bf2e-914e4ae260d6@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8AuPXBqFMi=WCk=8=OR=SmWnfP1-=Ct1DbkcvfmFUt=2Q@mail.gmail.com>
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>
 <CAMW7n8AuPXBqFMi=WCk=8=OR=SmWnfP1-=Ct1DbkcvfmFUt=2Q@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
Content-Type: multipart/alternative;
 boundary=6fe1390be4484fd5b26c6bd1741cdbb2
From: rob@bottled.codes ("Rob Landers")

--6fe1390be4484fd5b26c6bd1741cdbb2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Nov 15, 2025, at 18:22, Edmond Dantes wrote:
> > To provide an explicit example for this, code that fits this pattern=
 is going to be problematic
>=20
> Why is this considered a problem if this behavior is part of the
> language=E2=80=99s contract?
> Exactly the same way as in Go for example, this is also part of the
> contract between the language and the programmer.

One of the stated goals of the RFC:

*Code that was originally written and intended to run outside of a Corou=
tine must work EXACTLY THE SAME inside a Coroutine without modifications=
.*

The examples you give here seem to contradict that. You are now saying t=
hat developers *must* refactor shared state, must avoid passing objects =
to multiple coroutines, and must adopt a certain programming style to av=
oid breaking existing code. That=E2=80=99s the opposite of "works exactl=
y the same without modification".

> > $this->data can be changed out from under writeData(), which leads t=
o unexpected behavior.
>=20
> So the developer must intentionally create two different coroutines.
> Intentionally pass them the same object.
> Intentionally write this code.
> And the behavior is called =E2=80=9Cunexpected=E2=80=9D? :)

The original claim of the RFC is that code *not written with coroutines =
in mind* should still behave the same inside them. If any function can s=
uspend at arbitrary points, the ordinary synchronous assumptions, includ=
ing read/modify/write patterns on properties, no longer hold. Whether th=
at pattern is good style or not doesn=E2=80=99t change the fact that the=
 behaviour is different once asynchrony is introduced.

> A developer must understand that potentially any function can
> interrupt execution. This is a consequence of transparent asynchrony.

This is also a direct tension with another major goal:

*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 cas=
es where they consciously choose to intervene in this logic.*

If any function can suspend, then developers MUST reason about all the u=
sual concurrency hazards: torn writes, interleaving, race conditions, an=
d the entire class of bugs that coloured function models prevent. That a=
bsolutely counts as "thinking about coroutine switching".

> It is both its strength and its weakness. I will repeat it again: not
> some specific function, but almost ANY function. Because under
> transparent asynchrony you can use suspend() inside any function. This
> does not negate the fact that documentation should list all functions
> that switch context, but a certain coding style encourages this way of
> thinking.

These statements also seem to go against another goal of the RFC:

*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 cas=
es where they consciously choose to intervene in this logic.*

> How did we refactor old code for coroutines?
>=20
> 1. We took the modules that had global state. There were not many of t=
hem.
> 2. We used a Context, which is essential, and moved the global state
> into the context.
> [snip]
> But why anyone would intentionally pass the same object to different
> coroutines and then complain that the code broke. I have no idea who
> would need that. :)

Existing PHP codes does this today without issue. Many libraries, parser=
s, database clients, stream decorators, in-memory caches, DTOs, middlewa=
re chains ... are built around shared mutable objects. That style is ext=
remely common in PHP, and today it=E2=80=99s perfectly fine to share the=
se things.

Saying "just refactor all your shared-state-code" seems to contradict th=
e goals given in the RFC.

> A developer should strive to minimize asynchronous code in a project.
> The less of it there is, the better. Asynchronous code is evil. An
> anti-pattern. A high-complexity zone. But if a developer chooses to
> use asynchronous code, they shouldn=E2=80=99t act like they=E2=80=99re=
 three years old
> and seeing a computer for the first time. Definitely not. This
> technology requires steady, capable hands :)
>=20
> Best Regards, Ed.

Right now, today, PHP has almost zero async code in the ecosystem. If th=
e position of the RFC is that transparent asynchrony is inherently dange=
rous, requires careful discipline, breaks common patterns, and requires =
refactoring shared state, then it isn=E2=80=99t clear how the central va=
lue proposition "existing code works unchanged" is meant to hold.

This is why the semantics need to be written down explicitly, not left t=
o implication or the experience of those who already work with coroutine=
s.

=E2=80=94 Rob
--6fe1390be4484fd5b26c6bd1741cdbb2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Nov 15, 2025, at 18:22, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; To provide =
an explicit example for this, code that fits this pattern is going to be=
 problematic</div><div><br></div><div>Why is this considered a problem i=
f this behavior is part of the</div><div>language=E2=80=99s contract?</d=
iv><div>Exactly the same way as in Go for example, this is also part of =
the</div><div>contract between the language and the programmer.</div></b=
lockquote><div><br></div><div>One of the stated goals of the RFC:</div><=
div><br></div><div><b>Code that was originally written and intended to r=
un outside of a Coroutine must work EXACTLY THE SAME inside a Coroutine =
without modifications.</b><br></div><div><br></div><div>The examples you=
 give here seem to contradict that. You are now saying that developers&n=
bsp;<i>must</i> refactor shared state, must avoid passing objects to mul=
tiple coroutines, and must adopt a certain programming style to avoid br=
eaking existing code. That=E2=80=99s the opposite of "works exactly the =
same without modification".</div><div><br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div>&gt; $this-&gt;data can be changed out from =
under writeData(), which leads to unexpected behavior.</div><div><br></d=
iv><div>So the developer must intentionally create two different corouti=
nes.</div><div>Intentionally pass them the same object.</div><div>Intent=
ionally write this code.</div><div>And the behavior is called =E2=80=9Cu=
nexpected=E2=80=9D? :)</div></blockquote><div><br></div><div>The origina=
l claim of the RFC is that code&nbsp;<i>not written with coroutines in m=
ind</i> should still behave the same inside them. If any function can su=
spend at arbitrary points, the ordinary synchronous assumptions, includi=
ng read/modify/write patterns on properties, no longer hold. Whether tha=
t pattern is good style or not doesn=E2=80=99t change the fact that the =
behaviour is different once asynchrony is introduced.</div><div><br></di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div>A developer must u=
nderstand that potentially any function can</div><div>interrupt executio=
n. This is a consequence of transparent asynchrony.</div></blockquote><d=
iv><br></div><div>This is also a direct tension with another major goal:=
</div><div><br></div><div><b>A PHP developer should not have to think ab=
out 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.</b></div><div><br></div><div>If any function can suspend=
, then developers MUST reason about all the usual concurrency hazards: t=
orn writes, interleaving, race conditions, and the entire class of bugs =
that coloured function models prevent. That absolutely counts as "thinki=
ng about coroutine switching".<br></div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>It is both its strength and its weaknes=
s. I will repeat it again: not</div><div>some specific function, but alm=
ost ANY function. Because under</div><div>transparent asynchrony you can=
 use suspend() inside any function. This</div><div>does not negate the f=
act that documentation should list all functions</div><div>that switch c=
ontext, but a certain coding style encourages this way of</div><div>thin=
king.</div></blockquote><div><br></div><div>These statements also seem t=
o go against another goal of the RFC:</div><div><br></div><div><b>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 wher=
e they consciously choose to intervene in this logic.</b><br></div><div>=
<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>How did we=
 refactor old code for coroutines?</div><div><br></div><div>1. We took t=
he modules that had global state. There were not many of them.</div><div=
>2. We used a Context, which is essential, and moved the global state</d=
iv><div>into the context.</div><div>[snip]</div><div>But why anyone woul=
d intentionally pass the same object to different</div><div>coroutines a=
nd then complain that the code broke. I have no idea who</div><div>would=
 need that. :)</div></blockquote><div><br></div><div>Existing PHP codes =
does this today without issue. Many libraries, parsers, database clients=
, stream decorators, in-memory caches, DTOs, middleware chains ... are b=
uilt around shared mutable objects. That style is extremely common in PH=
P, and today it=E2=80=99s perfectly fine to share these things.</div><di=
v><br></div><div>Saying "just refactor all your shared-state-code" seems=
 to contradict the goals given in the RFC.<br></div><div><br></div><bloc=
kquote type=3D"cite" id=3D"qt" style=3D""><div>A developer should strive=
 to minimize asynchronous code in a project.</div><div>The less of it th=
ere is, the better. Asynchronous code is evil. An</div><div>anti-pattern=
. A high-complexity zone. But if a developer chooses to</div><div>use as=
ynchronous code, they shouldn=E2=80=99t act like they=E2=80=99re three y=
ears old</div><div>and seeing a computer for the first time. Definitely =
not. This</div><div>technology requires steady, capable hands :)</div><d=
iv><br></div><div>Best Regards, Ed.</div></blockquote><div><br></div><di=
v>Right now, today, PHP has almost zero async code in the ecosystem. If =
the position of the RFC is that transparent asynchrony is inherently dan=
gerous, requires careful discipline, breaks common patterns, and require=
s refactoring shared state, then it isn=E2=80=99t clear how the central =
value proposition "existing code works unchanged" is meant to hold.</div=
><div><br></div><div>This is why the semantics need to be written down e=
xplicitly, not left to implication or the experience of those who alread=
y work with coroutines.</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob</div></body></html>
--6fe1390be4484fd5b26c6bd1741cdbb2--