Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128908
Content-Type: text/plain;
	charset=us-ascii
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
In-Reply-To: <CAMW7n8B_+fBQEWoB6f2nNM7CPH5MfAHQ154dbyMLmDCS6-4Mhw@mail.gmail.com>
Date: Wed, 22 Oct 2025 13:24:31 -0400
Cc: Rob Landers <rob@bottled.codes>,
 Aleksander Machniak <alec@alec.pl>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C3EEAC36-A8ED-4B82-BDFC-879EF923E079@zort.net>
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
 <CAMW7n8AgHnO0rBjqBkHNhfvV5PBNxwgHBJ762N3FtVxoh5WnOQ@mail.gmail.com>
 <E8D4A549-79EA-48E9-9D20-3608F357F227@trowski.com>
 <CAMW7n8D0wMNQE0zuMhbHstyZsDw=e7ryPPZERn11UFV7knmR-g@mail.gmail.com>
 <37180d8d-85b4-49a3-a672-334bf4329470@app.fastmail.com>
 <CAMW7n8AFaUByiJ=2frgkAFWNPWHS2wYyHiKfwf8dzT7AYnLjWg@mail.gmail.com>
 <2f8524a7-dea2-4fbf-933a-c538d3706253@app.fastmail.com>
 <CAMW7n8DKB+AWp2sWPi_w8ZgLQ_zS2MPNgP6n1G5127Nkk7EgOA@mail.gmail.com>
 <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
 <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@mail.gmail.com>
 <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com>
 <CAMW7n8B_+fBQEWoB6f2nNM7CPH5MfAHQ154dbyMLmDCS6-4Mhw@mail.gmail.com>
To: Edmond Dantes <edmond.ht@gmail.com>
From: jbafford@zort.net (John Bafford)

Hi Edmond,

> On Oct 22, 2025, at 09:09, Edmond Dantes <edmond.ht@gmail.com> wrote:

Thanks for putting in the work to start to bring async support to PHP. I =
have a few initial comments:


* Is TrueAsync intended strictly to enable concurrency without =
parallelism (e.g. single-threaded cooperative multitasking)? Is there a =
future path in mind for parallelism (actual simultaneous execution)?



* Following on from that question, I note that there is no way to =
annotate types as being safely sendable across concurrent execution =
contexts. PHP does have a thread-safe ZTS mode. And a long-term goal =
should be to allow for parallel (multiple concurrent execution) =
asynchronous tasks, especially if we want to expand asynchronous from =
just being a way to accomplish other single-threaded work while waiting =
on I/O.

In a concurrent environment, one has to consider the effects of multiple =
threads trying to read or write from the same value at once. (Strictly =
speaking, even in a single-threaded world, that's not necessarily safe =
to ignore; the stdclib or kernel code behind the scenes may be doing all =
sorts of shenanigans with I/O behind everyone's back, though I suspect =
an async-aware PHP could itself be a sufficient buffer between that and =
userspace code.)

With multithreaded code, it's generally not safe to pass around types =
unless you can reason about whether it's actually safe to do so. This =
could be trivially encoded in the type system with, say, a marker =
interface that declares that a type is safe to send across threads. But =
this needs to be opt-in, and the compiler needs to enforce it, or else =
you lose all pretense of safety.

It's tempting to handwave this now, but adding it in later might prove =
intractable due to the implied BC break. E.g. trivially, any call to =
spawn() might have its task scheduled on a different thread, but you =
can't do that safely unless you know all types involved are thread-safe. =
And while you could determine that at runtime, that's far more expensive =
and error-prone than making the compiler do it.

That said: the TrueAsync proposal isn't proposing async/await keywords. =
Perhaps it's sufficient to say that "TrueAsync" is single-thread only, =
and the multithreaded case will be handled with a completely different =
API later so BC isn't an issue. But either way, this should be at least =
mentioned in the Future Scope section.



* Rob Landers brought up the question about multiple-value Awaitables. I =
agree with him that it is a potential footgun. If an Awaitable is going =
to return multiple values, then it should implement have a different =
interface to indicate that contract.

Returning multiple values is fundamentally different than returning one =
value, and providing space for a contract change of that magnitude =
without reflecting in the type system is likely to cause significant =
problems as async interfaces evolve. Doing so would be like allowing a =
function that is defined to return an int to actually return an array of =
ints with no change to its type. That is clearly wrong. One should be =
able to look at a type definition and tell from its interfaces whether =
it is single-value or multiple-value.

(For example: Swift's standard library provides the AsyncSequence =
interface that one uses when wanting to asynchronously stream values. A =
concrete AsyncStream type provides an implementation of AsyncSequence =
that allows easily converting callback-based value streaming into an =
asynchronous sequence that can be iterated on with a for await loop. You =
don't await on an AsyncSequence type itself; instead you get an iterator =
and use the iterator to get values until the iterator returns null or =
throws an error. This is assisted with the syntactic sugar of a `for =
await` loop.)


Rob: The answer in Swift to what happens if multiple readers await a =
non-idempotent Awaiter (e.g., there are multiple readers for an =
AsyncSequence) is that as new values are made available, they go in turn =
to whatever readers are awaiting. So if you have five readers of an =
AsyncSequence, and the sequence emits ten values, they may all go to one =
reader, or each reader might get two values, or any combination thereof, =
depending on core count and how the scheduler schedules the tasks. So =
this can be used to spread workload across multiple threads, but if you =
need each reader to get all the values, you need to reach for other =
constructs.

I don't have a particular view on whether values should be replicated to =
multiple readers or not, but I do find it a bit annoying that Swift's =
standard library doesn't provide an easy way to get replicated values. =
So whichever way PHP goes, it should be clearly documented, _and_ there =
be an easy way to get the other behavior.


* For cancellation, I'm confused on the resulting value. The section on =
cancellation suggests ("If a coroutine has already completed, nothing =
happens.") but does not explicitly state that an already-completed =
coroutine will have its return value preserved. The section on =
self-cancellation explicitly says that a self-cancelled coroutine throws =
away its return value, despite ultimately successfully completing. This =
seems counter-intuitive. Why should a self-cancellation be treated =
differently than an external cancellation? If the task completes through =
to the end and doesn't emit that it was cancelled, why should its return =
value be ignored in some cases and preserved in others?

I think self-cancellation is a weird edge case. It should probably be =
prohibited like self-await is. In general, I think a coroutine shouldn't =
ever have a handle to itself. Why would it need that? If a coroutine =
needs to abort early, it should throw or emit a partial result directly, =
rather than using the cancel mechanism.



* exit/die called within a cooroutine is defined (to immediately =
terminate the app). For clarity, the case when exit/die is called =
outside of async code while there is a coroutine executing should also =
be explicitly documented. (Presumably this means that the async code is =
immediately terminated, but you don't state that, and Async\protect() =
would suggest that maybe it doesn't always apply.)



* I think Async\protect() and forcibly cancelling coroutines beyond =
calling $coroutine->cancel() should be removed. Async\protect() is the =
answer to "but I need to make sure that this gets completed when a task =
is forcibly cancelled". But that just begs for a =
$scope->reallyCancelEvenProtectedCoroutines() and a Async\superProtect() =
to bypass that, and so on.

Yes, this means that a coroutine might never complete. But this is no =
different than non-async code calling a function that has an infinite =
loop and never returns.



* Aleksander Machniak brought up possibly merging suspend and delay. As =
you note, they are semantically different (delay for a specified time =
interval, vs. cooperatively yield execution for an unspecified time), =
and I think they should stay separate. If we're bikeshedding, I might =
rename suspend() to yield(), though that might not be possible with =
yield being a language keyword. That could be worked around if yield() =
was, say, a static method on Coroutine, so you would call =
Coroutine::yield() to yield the current coroutine. (That could also =
apply to isCancelled, so a particular coroutine would never need to have =
a reference to itself to check if cancellation is requested.)



* Also bikeshedding, but I would suggest renaming Coroutine to Task. =
Task is shorter and much easier to say and type, but more importantly, =
it encourages thinking about the effect (code that will eventually =
return a value), rather than how that effect is achieved. It also means =
the same abstraction can be used in a multithreaded environment.


-John