Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126582
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <CAEKnhAHv_3bR+Fnmg=mGXuDJhpmAjTMwj0VhAt8TOcjiD+YJzw@mail.gmail.com>
 <CAMW7n8DHFb6innyn6VigDtQGb9EYu9-H_v5m_XGJWHEQG+q2OA@mail.gmail.com> <CAEKnhAGc-hOPkEfiBouA+XD0A1oEjt1jtg_u=uZohbbDYg=7Pg@mail.gmail.com>
In-Reply-To: <CAEKnhAGc-hOPkEfiBouA+XD0A1oEjt1jtg_u=uZohbbDYg=7Pg@mail.gmail.com>
Date: Wed, 5 Mar 2025 19:50:37 +0200
Message-ID: <CAMW7n8BDFYJ=U9=LbL83fD6k9gPM2PThzfB0BhDZLm2c7ovocA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Jakub Zelenka <bukka@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008af43a062f9c079b"
From: edmond.ht@gmail.com (Edmond Dantes)

--0000000000008af43a062f9c079b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  You might want to look to parallel extension as it's already dealing
> with that and mostly works - of course combination with coroutines will
certainly complicate it but the point is that memory is not shared.

Do you mean this extension: https://www.php.net/manual/en/book.parallel.php=
?

Yes, I studied it before starting the development of True Async. My very
first goal was to enable, if not coroutine execution across threads, then
at least interaction, because the same thing is already possible with
Swoole.

However, parallel does not provide multitasking and will not be able to in
the future. The best it can offer is interaction via Channel between two
different threads, which will be useful for job processing and built-in web
servers.

And here's the frustrating part. It turns out that parallel has to copy PHP
bytecode for correct execution in another thread. This means that not only
does the memory manager need to be replaced with a multi-threaded version,
but the virtual machine itself must also be refactored.

For PHP to work correctly in multiple threads with context switching, it
will be necessary to find a way to rewrite all the code that reads/writes
global variables. (Where TLS macros are used, this shouldn't be too
difficult. But is that the case everywhere?) This applies to all
extensions, both built-in and third-party.

Such a language update would create an "extension vacuum." When a new
version is released, many extensions will become unavailable due to the
need to adapt to the new multitasking model.

> I didn't really mean to introduce it as part of this RFC.
> What I meant is to design the API so there is still possibility to add it
in the future without risking various race condition in the code.
> It means primarily to put certain restrictions that will prevent it like
limited access to global and passing anything by
> reference (including objects) to the running tasks.

Primitives like *Context* are unlikely to be the main issue for
multitasking. The main problem will be the code that has been developed for
many years with single-threaded execution in mind. This is another factor
that raises doubts about the rationale for introducing real multitasking in
PHP.

If we are talking about a model similar to Python=E2=80=99s, the current RF=
C
already works with it, as a separate thread is used on Windows to wait for
processes and send events to the PHP thread. Therefore, integrating this
RFC with parallel is not an issue.

It would be great to solve the bytecode problem in a way that allows it to
be freely executed across different threads. This would enable running any
closure as a coroutine in another OS thread and interacting through a
channel. If you talk about this  functionality, it does not block
concurrency or current RFC.  This capability should be considered as an
additional feature that can be implemented later without modifying the
existing primitives.

While working on this RFC, I also considered finding a way to create
SharedObject instances that could be passed between threads. However, I
ultimately concluded that this solution would require changes to the memory
manager, so these objects were not included in the final document.

Ed.

--0000000000008af43a062f9c079b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0

You might want to look to parallel extension as it&#39;s already dealing <b=
r>&gt; with that and mostly works - of course combination with coroutines w=
ill certainly complicate it but the point is that memory is not shared.<div=
><br></div><div><p>Do you mean this extension: <a href=3D"https://www.php.n=
et/manual/en/book.parallel.php">https://www.php.net/manual/en/book.parallel=
.php</a>?</p><p>Yes, I studied it before starting the development of True A=
sync. My very first goal was to enable, if not coroutine execution across t=
hreads, then at least interaction, because the same thing is already possib=
le with Swoole.</p><p>However, <code>parallel</code> does not provide multi=
tasking and will not be able to in the future. The best it can offer is int=
eraction via <code>Channel</code> between two different threads, which will=
 be useful for job processing and built-in web servers.</p><p>And here&#39;=
s the frustrating part. It turns out that <code>parallel</code> has to copy=
 PHP bytecode for correct execution in another thread. This means that not =
only does the memory manager need to be replaced with a multi-threaded vers=
ion, but the virtual machine itself must also be refactored.</p><p>For PHP =
to work correctly in multiple threads with context switching, it will be ne=
cessary to find a way to rewrite all the code that reads/writes global vari=
ables. (Where TLS macros are used, this shouldn&#39;t be too difficult. But=
 is that the case everywhere?) This applies to all extensions, both built-i=
n and third-party.</p><p>Such a language update would create an &quot;exten=
sion vacuum.&quot; When a new version is released, many extensions will bec=
ome unavailable due to the need to adapt to the new multitasking model.</p>=
<p>&gt; I didn&#39;t really mean to introduce it as part of this RFC.<br>&g=
t; What I meant is to design the API so there is still possibility to add i=
t in the future without risking various race condition in the code. <br>&gt=
; It means primarily to put certain restrictions that will prevent it like =
limited access to global and passing anything by <br>&gt; reference (includ=
ing objects) to the running tasks.</p><p>Primitives like <strong>Context</s=
trong> are unlikely to be the main issue for multitasking. The main problem=
 will be the code that has been developed for many years with single-thread=
ed execution in mind. This is another factor that raises doubts about the r=
ationale for introducing real multitasking in PHP.</p><p>If we are talking =
about a model similar to Python=E2=80=99s, the current RFC already works wi=
th it, as a separate thread is used on Windows to wait for processes and se=
nd events to the PHP thread. Therefore, integrating this RFC with <code>par=
allel</code> is not an issue.</p><p>It would be great to solve the bytecode=
 problem in a way that allows it to be freely executed across different thr=
eads. This would enable running any closure as a coroutine in another OS th=
read and interacting through a channel. If you talk about this=C2=A0 functi=
onality, it does not block concurrency or current RFC.=C2=A0

This capability should be considered as an additional feature that can be i=
mplemented later without modifying the existing primitives.

</p><p>While working on this RFC, I also considered finding a way to create=
 <code>SharedObject</code> instances that could be passed between threads. =
However, I ultimately concluded that this solution would require changes to=
 the memory manager, so these objects were not included in the final docume=
nt.</p><p>Ed.</p></div></div>

--0000000000008af43a062f9c079b--