Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129748
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 10 Jan 2026 12:25:50 +0100
To: internals@lists.php.net
Message-ID: <926941aa-f33d-49f0-b23e-32dd3022075e@app.fastmail.com>
In-Reply-To: 
 <CAE6GH03pVxstk8ssJhMfMTT-=S+3+Usk=7g1CarCb+NBB_7TDw@mail.gmail.com>
References: 
 <CAE6GH03pVxstk8ssJhMfMTT-=S+3+Usk=7g1CarCb+NBB_7TDw@mail.gmail.com>
Subject: Re: [PHP-DEV] Analogue of Node.js Worker threads?
Content-Type: multipart/alternative;
 boundary=98f8e698beaf44caa87c49db750164b5
From: rob@bottled.codes ("Rob Landers")

--98f8e698beaf44caa87c49db750164b5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Jan 10, 2026, at 09:19, Pavel Shevaev wrote:
> Hi!
>=20
> Historically in my company PHP has been used as a CLI tool for project=
 building purposes. For example for code generation, configs parsing and=
 converting them into binary blobs, calling dotnet and go tools, etc. In=
 general it's a cross platform 'make on steroids'.=20
>=20
> We are pretty much happy about it except one particular thing: conveni=
ent cross platform multi-threading. And we don't actually need a true mu=
lti-threading but rather something similar to Worker threads in Node.js.=20
>=20
> We tried using the AMPHP Parallel package but it wasn't stable enough =
for our needs (hangs or emits serialization errors for our workloads). A=
nd it also seems to be using a special 'ProcessWrapper.exe' (bundled wit=
h a composer package) to overcome some Window specific issues. Due to st=
rict anti-virus policies we had to manually add an exception for it... S=
o we ended up with some primitive wrappers around platform specific tool=
s: for *nix we start background PHP processes with '&', for Windows - us=
ing 'powershell.exe Start-Process' for the same purpose. We pass data to=
 and from these background processes using serialization and temporary f=
iles and while it works, well, it's pretty inconvenient and cumbersome. =20
>=20
> Out of curiosity I tried Node.js Worker threads and it just worked as =
expected for our sample loads both on *nix and Windows boxes. And there =
are some high-level wrappers over Worker threads like Piscina which simp=
lify things even further:
>=20
>     const worker =3D new Piscina({
>       filename: path.resolve(__dirname, "worker.js"),
>       maxThreads: 32,
>       maxQueue: "auto",
>     });
>=20
>     const results =3D await Promise.all(
>       files.map((file, idx) =3D> worker.run([file]))
>     )
> I think PHP could benefit from having the similar 'multi-processing' s=
upport in the core. It seems like here's what Node.js does:
> 1) Spawns/stops worker threads
> 2) Passes serialized input/output between the worker manager and worke=
r threads
>=20
> Since worker threads are fully isolated you can't directly access thei=
r internal data, there are no data races and there's no need for any syn=
chronization primitives.=20
>=20
> I guess PHP could do the same even in non ZTS mode? And the aforementi=
oned AMPHP could use this built-in Worker threads support without having=
 to resort to any platform specific hacks providing a nice and clean int=
erface. =20
>=20
> --
> Best regards, Pavel

Hi Pavel,

It isn=E2=80=99t directly possible to share zvals between threads. They =
must be copied/serialized, and the context reconstructed. That=E2=80=99s=
 why the parallel extension works the way it does. There=E2=80=99s also =
the phasync library that does this stuff in non-zts PHP, if you=E2=80=99=
re interested in a solution you can use today. I don=E2=80=99t know if i=
t is used in production, but the maintainer is pretty responsive.

There=E2=80=99s some work to make this easier (me refactoring TSM, TrueA=
sync), but it probably won=E2=80=99t be a thing until PHP 9.0.=20

=E2=80=94 Rob
--98f8e698beaf44caa87c49db750164b5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Sat, Jan 10, 2026, at 09:19, Pavel Shevaev wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div=
>Hi!</div><div><br></div><div>Historically in my company PHP has been us=
ed as a CLI tool for project building purposes. For example for code gen=
eration, configs parsing and converting them into binary blobs, calling =
dotnet and go tools, etc. In general it's a cross platform 'make on ster=
oids'.&nbsp;</div><div><br></div><div><div>We are pretty much happy abou=
t it except one particular thing: convenient cross platform multi-thread=
ing. And we don't actually need a true multi-threading but rather someth=
ing similar to Worker threads in Node.js. </div><div><br></div><div>We t=
ried using the AMPHP Parallel package but it wasn't stable enough for ou=
r&nbsp;needs (hangs or emits serialization errors for our&nbsp;workloads=
). And it also seems to be using a special 'ProcessWrapper.exe' (bundled=
 with a composer package) to overcome some Window specific&nbsp;issues. =
Due to strict anti-virus policies we had to manually add an exception fo=
r it... So we ended up with some primitive wrappers around platform spec=
ific tools: for *nix we start background PHP processes with '&amp;', for=
 Windows - using 'powershell.exe Start-Process' for the same purpose. We=
 pass data to and from these background processes using serialization an=
d temporary&nbsp;files and while it works, well, it's pretty inconvenien=
t and cumbersome.&nbsp;&nbsp;</div><div><br></div><div>Out&nbsp;of curio=
sity I tried Node.js Worker threads and it just worked as expected for o=
ur sample loads both on *nix and Windows boxes. And there are some high-=
level wrappers over Worker threads like Piscina which simplify things ev=
en further:</div><div><br></div><div>&nbsp; &nbsp; const worker =3D new =
Piscina({</div><div>&nbsp; &nbsp; &nbsp; filename: path.resolve(__dirnam=
e, "worker.js"),</div><div>&nbsp; &nbsp; &nbsp; maxThreads: 32,</div><di=
v>&nbsp; &nbsp; &nbsp; maxQueue: "auto",</div><div>&nbsp; &nbsp; });</di=
v><div><br></div><div>&nbsp; &nbsp; const results =3D await Promise.all(=
</div><div>&nbsp; &nbsp; &nbsp; files.map((file, idx) =3D&gt; worker.run=
([file]))</div><div>&nbsp; &nbsp; )</div></div><div><div>I think PHP cou=
ld benefit from having the similar 'multi-processing' support in the cor=
e. It seems like here's what Node.js does:</div><div>1) Spawns/stops wor=
ker threads</div><div>2) Passes serialized input/output between the work=
er manager and worker threads</div><div><br></div><div>Since worker thre=
ads are fully isolated you can't directly access their internal data, th=
ere are no data races and there's no need for any synchronization primit=
ives. </div><div><br></div><div>I guess PHP could do the same even in no=
n ZTS mode? And the aforementioned AMPHP could use this built-in Worker =
threads support without having to resort to any platform specific hacks =
providing a nice and clean interface.&nbsp;&nbsp;</div><div><br></div></=
div><div><span class=3D"qt-gmail_signature_prefix">--</span></div><div d=
ir=3D"ltr" class=3D"qt-gmail_signature">Best regards, Pavel</div></div><=
/blockquote><div><br></div><div>Hi Pavel,</div><div><br></div><div>It is=
n=E2=80=99t directly possible to share zvals between threads. They must =
be copied/serialized, and the context reconstructed. That=E2=80=99s why =
the parallel extension works the way it does. There=E2=80=99s also the p=
hasync library that does this stuff in non-zts PHP, if you=E2=80=99re in=
terested in a solution you can use today. I don=E2=80=99t know if it is =
used in production, but the maintainer is pretty responsive.</div><div><=
br></div><div>There=E2=80=99s some work to make this easier (me refactor=
ing TSM, TrueAsync), but it probably won=E2=80=99t be a thing until PHP =
9.0.&nbsp;</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</d=
iv></body></html>
--98f8e698beaf44caa87c49db750164b5--