Re: PHP True Async RFC Stage 4

On Wed, Oct 22, 2025, at 19:24, John Bafford wrote: > 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. Off-topic a bit: but for the last several+ weeks, I’ve been reworking TSRM (moving it into Zend & making it a bit more frankenphp friendly) which could -- eventually -- allow for passing arbitrary types between threads without complex serialization and shenanigans. — Rob