Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128949
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 24 Oct 2025 12:11:13 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <85376b2e-88f1-4e63-a8a5-f50ab23100db@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8B5-W-ObyXTU7iCdBkVsLQp8XZK7pAQiuJT3GUz0YDByw@mail.gmail.com>
References: 
 <CAMW7n8CdUGSdXWnBM_ENCRaM6tqJta0n3sZF3y=WhFGdtajQbg@mail.gmail.com>
 <b7af2a5f-cffa-4668-99aa-495ed82b0cb0@app.fastmail.com>
 <CAMW7n8CMFst0DESarE0stVtaEKnaZzgW7iga7O+qBNH9t0cYMg@mail.gmail.com>
 <0c852933-607a-4d50-94a8-641a3318f3c9@app.fastmail.com>
 <CAMW7n8B5-W-ObyXTU7iCdBkVsLQp8XZK7pAQiuJT3GUz0YDByw@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP and parallelism
Content-Type: multipart/alternative;
 boundary=6cf5f86835084403b0e9b17b6c086945
From: rob@bottled.codes ("Rob Landers")

--6cf5f86835084403b0e9b17b6c086945
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 24, 2025, at 11:43, Edmond Dantes wrote:
> >
> > So practically speaking, it=E2=80=99s not worth designing around thi=
s yet. The engine would need massive adaptation before userland could sa=
fely talk about =E2=80=9Cparallelism.=E2=80=9D
> >
>=20
> I agree. However, this question was raised. Perhaps there=E2=80=99s a =
larger
> team of developers working on a new virtual machine for PHP? I don=E2=80=
=99t
> know anything about that. But if that=E2=80=99s indeed happening, then=
 the
> topic becomes relevant.
>=20
> As for me personally, I don=E2=80=99t see any practical benefit in int=
roducing
> multitasking to PHP. It would require significant development effort
> while offering very little economic value in typical PHP use cases.
> Still, it=E2=80=99s possible that someone plans to build a PHP-Native =
version
> for a wider range of operating systems =E2=80=94 and in that case, suc=
h a
> feature might indeed be needed.
>=20
> --- 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 =E2=80=93 not that you'd ev=
er want to do it, unless you like segfaults =E2=80=93 to run the engine =
concurrently across multiple threads. With a decent preemptive scheduler=
 (this is distinct from the userland/TrueAsync scheduler), you could pac=
k 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 b=
e entirely transparent to userland and other than TSRM changes and a few=
 convienent hooks, be handled completely by a FrankenPHP (or even, Swool=
e) scheduler.

Where this intersects with TrueAsync is being able to further pack corou=
tines (and especially "native" coroutines like file_get_contents(), PDO,=
 etc) across fewer threads, making full use of CPUs. There is no need fo=
r parallelism in this model =E2=80=93 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 e=
veryone, to focus on that, and not this. At least right now, it is a was=
te of everyone's time.

That's my roadmap for FrankenPHP over the coming *years* and they're alm=
ost completely unrelated to coroutines and TrueAsync.

=E2=80=94 Rob
--6cf5f86835084403b0e9b17b6c086945
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Fri, Oct =
24, 2025, at 11:43, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt;</div><div>&gt; So practically speaking, i=
t=E2=80=99s not worth designing around this yet. The engine would need m=
assive adaptation before userland could safely talk about =E2=80=9Cparal=
lelism.=E2=80=9D</div><div>&gt;</div><div><br></div><div>I agree. Howeve=
r, this question was raised. Perhaps there=E2=80=99s a larger</div><div>=
team of developers working on a new virtual machine for PHP? I don=E2=80=
=99t</div><div>know anything about that. But if that=E2=80=99s indeed ha=
ppening, then the</div><div>topic becomes relevant.</div><div><br></div>=
<div>As for me personally, I don=E2=80=99t see any practical benefit in =
introducing</div><div>multitasking to PHP. It would require significant =
development effort</div><div>while offering very little economic value i=
n typical PHP use cases.</div><div>Still, it=E2=80=99s possible that som=
eone plans to build a PHP-Native version</div><div>for a wider range of =
operating systems =E2=80=94 and in that case, such a</div><div>feature m=
ight indeed be needed.</div><div><br></div><div>--- Ed</div></blockquote=
><div><br></div><div>The only thing that is relevant to this discussion =
(that I know of), is my refactoring of TSRM so that FrankenPHP doesn't n=
eed 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 =E2=80=
=93 not that you'd ever want to do it, unless you like segfaults =E2=80=93=
 to run the engine concurrently across multiple threads. With a decent p=
reemptive scheduler (this is distinct from the userland/TrueAsync schedu=
ler), 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 TSR=
M changes and a few convienent hooks, be handled completely by a Franken=
PHP (or even, Swoole) scheduler.</div><div><br></div><div>Where this int=
ersects with TrueAsync is being able to further pack coroutines (and esp=
ecially "native" coroutines like file_get_contents(), PDO, etc) across f=
ewer threads, making full use of CPUs. There is no need for parallelism =
in this model =E2=80=93 at least when it comes to it being visible to us=
erland. And this is just pie-in-the-sky thinking, because first, TrueAsy=
nc needs to be worked on. It would be more beneficial to everyone, to fo=
cus on that, and not this. At least right now, it is a waste of everyone=
's time.</div><div><br></div><div>That's my roadmap for FrankenPHP over =
the coming&nbsp;<b>years</b> and they're almost completely unrelated to =
coroutines and TrueAsync.</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob</div></body></html>
--6cf5f86835084403b0e9b17b6c086945--