Re: PHP True Async RFC Stage 4

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