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