Re: PHP and parallelism

From: Date: Fri, 24 Oct 2025 10:11:13 +0000
Subject: Re: PHP and parallelism
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-128949@lists.php.net to get a copy of this message
On Fri, Oct 24, 2025, at 11:43, Edmond Dantes wrote:
> >
> > So practically speaking, it’s not worth designing around this yet. The engine would need
> > massive adaptation before userland could safely talk about “parallelism.”
> >
> 
> I agree. However, this question was raised. Perhaps there’s a larger
> team of developers working on a new virtual machine for PHP? I don’t
> know anything about that. But if that’s indeed happening, then the
> topic becomes relevant.
> 
> As for me personally, I don’t see any practical benefit in introducing
> multitasking to PHP. It would require significant development effort
> while offering very little economic value in typical PHP use cases.
> Still, it’s possible that someone plans to build a PHP-Native version
> for a wider range of operating systems — and in that case, such a
> feature might indeed be needed.
> 
> --- Ed

The only thing that is relevant to this discussion (that I know of), is my refactoring of TSRM so
that FrankenPHP doesn't need to maintain it's own thread pool of PHP workers. It's
only relevant because it takes away the thread-local bits and makes it possible – not that
you'd ever want to do it, unless you like segfaults – to run the engine concurrently across
multiple threads. With a decent preemptive scheduler (this is distinct from the userland/TrueAsync
scheduler), you could pack multiple requests in the same thread while waiting on I/O, and have a
different thread pick up work if the I/O finished too early. This will be entirely transparent to
userland and other than TSRM changes and a few convienent hooks, be handled completely by a
FrankenPHP (or even, Swoole) scheduler.

Where this intersects with TrueAsync is being able to further pack coroutines (and especially
"native" coroutines like file_get_contents(), PDO, etc) across fewer threads, making full
use of CPUs. There is no need for parallelism in this model – at least when it comes to it being
visible to userland. And this is just pie-in-the-sky thinking, because first, TrueAsync needs to be
worked on. It would be more beneficial to everyone, to focus on that, and not this. At least right
now, it is a waste of everyone's time.

That's my roadmap for FrankenPHP over the coming *years* and they're almost completely
unrelated to coroutines and TrueAsync.

— Rob


Thread (7 messages)

« previous php.internals (#128949) next »