Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129234
Content-Type: text/plain;
	charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
In-Reply-To: <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com>
Date: Sat, 15 Nov 2025 11:20:41 -0500
Cc: php internals <internals@lists.php.net>,
 Jakub Zelenka <bukka@php.net>,
 Larry Garfield <larry@garfieldtech.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Rob Landers <rob@bottled.codes>,
 Edmond Dantes <edmond.ht@gmail.com>
From: jbafford@zort.net (John Bafford)

Hi Rob, Edmond,

> 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 =
Coroutine must work EXACTLY THE SAME inside a Coroutine without =
modifications."
>=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 =
exactly where suspension can occur. This RFC=E2=80=99s implicit model =
seems convenient, but without clear rules about suspension points, I=E2=80=
=99m unclear how developers can write correct concurrent code or reason =
about 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 =
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 and took =
nearly a decade to get there. Earlier versions of Go explicitly stated =
where suspensions were.
>=20
> =E2=80=94 Rob

To provide an explicit example for this, code that fits this pattern is =
going to be problematic:

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 [];
}

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 cause =
a different coroutine to run, $this->data can be changed out from under =
writeData(), which leads to unexpected behavior. (e.g. $this->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 see there's a =
change and loses it when it clears the data).

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 =
correct 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 ignoring that it is now wrong.

Suspension points, whether explicit or hidden, allow for the entire rest =
of the world 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 course, 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.

-John