On Wed, Oct 22, 2025, at 19:24, John Bafford wrote: > Hi Edmond, > > > On Oct 22, 2025, at 09:09, Edmond Dantes <[email protected]> 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
