Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128944
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8CdUGSdXWnBM_ENCRaM6tqJta0n3sZF3y=WhFGdtajQbg@mail.gmail.com>
 <b7af2a5f-cffa-4668-99aa-495ed82b0cb0@app.fastmail.com>
In-Reply-To: <b7af2a5f-cffa-4668-99aa-495ed82b0cb0@app.fastmail.com>
Date: Fri, 24 Oct 2025 10:30:23 +0300
Message-ID: <CAMW7n8CMFst0DESarE0stVtaEKnaZzgW7iga7O+qBNH9t0cYMg@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP and parallelism
To: Rob Landers <rob@bottled.codes>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000730e760641e28691"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000730e760641e28691
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

But it's not a parallelism.

=D0=BF=D1=82, 24 =D0=BE=D0=BA=D1=82. 2025=E2=80=AF=D0=B3., 09:43 Rob Lander=
s <rob@bottled.codes>:

>
>
> On Fri, Oct 24, 2025, at 08:34, Edmond Dantes wrote:
>
> Hello everyone,
>
> In the TrueAsync RFC 4 thread, John Bafford raised a question about
> parallelism.
> I would like to share my thoughts and highlight this branch of the
> discussion.
>
> # What is parallelism in the context of coroutines?
> Parallelism for coroutines means the ability to execute a coroutine in
> one thread or another (but not simultaneously).
> In this case, the Scheduler not only manages the execution order of
> coroutines but also decides which thread from the thread pool should
> be assigned to a coroutine.
>
> # What is the problem?
>
> If two different coroutines run in separate threads and write to the
> same memory region =E2=80=94 that is, to the same PHP object =E2=80=94 it=
 will lead to
> unpredictable consequences.
>
> The issue is that PHP does not control memory access in such cases and
> effectively allows the programmer to shoot themselves in the head.
>
> How can this be solved?
>
> ### Object transfer policy
>
> The object transfer policy defines how a PHP object can be safely
> passed to another coroutine.
> Possible transfer methods:
> 1. Via parameters
> 2. Via context
> 3. Via channels
>
> All these methods can be viewed as variations of passing objects
> through channels (similar to the Erlang model =E2=80=94 no direct sharing=
).
>
> The same policy applies to all methods.
>
> An interface is defined to guarantee an object=E2=80=99s =E2=80=9Cthread =
safety.=E2=80=9D For
> example, if a coroutine receives an object parameter without this
> interface, an error occurs.
>
> In PHP, there are several possible ways to achieve thread safety:
> 1. **Ownership transfer**, as in C++/Rust =E2=80=94 the object leaves the
> current scope and becomes owned by the coroutine.
> 2. **Proxy-based access**, using a special constructor that creates a
> proxy object for access to the real one (similar to actors in Swift).
> 3. **Shared access** with a built-in mutex.
>
> This approach requires minimal changes to the language syntax =E2=80=94 i=
n
> fact, none at all.
> From a performance standpoint, it is perfectly acceptable for PHP to
> validate function parameters, so no significant overhead should be
> expected.
>
> The main challenge of parallelism lies in making PHP=E2=80=99s internal s=
tate,
> garbage collector, and memory manager thread-safe.
>
> # How does this relate to TrueAsync?
>
> At the moment, TrueAsync does not perform additional checks when
> passing parameters to coroutines.
> This is a problem =E2=80=94 because once PHP introduces concurrency,
> developers will start freely using references (&reference) and shared
> objects.
>
> When multitasking is later added to coroutines, it will break existing
> PHP code that has already been written.
>
> Therefore, if PHP truly aims to become multithreaded, its memory
> ownership model must be carefully designed today.
>
> ---
> Best Regards, Ed
>
>
> I=E2=80=99m not sure this is the place to discuss it, nor the time. But C=
# is
> cooperative multitasking on top of a VM which is preemptive multitasking.
> This basically allows you to run multithreaded without worrying about
> =E2=80=9Cshooting yourself in the foot=E2=80=9D by accessing the same mem=
ory, most of the
> time. In other words, there is plenty of prior art out there and ways to
> solve this problem. It doesn=E2=80=99t mean we need to solve it today. Tr=
ying to
> solve a problem that doesn=E2=80=99t currently exist and =E2=80=9Cmight=
=E2=80=9D be a problem later
> is exactly how you end up with overengineered solutions that never actual=
ly
> solve the problem.
>
> =E2=80=94 Rob
>

--000000000000730e760641e28691
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">But it&#39;s not a parallelism.=C2=A0</div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">=D0=BF=D1=82, 24 =D0=BE=D0=BA=D1=82. 2025=E2=80=AF=D0=B3., 09:43 Rob Land=
ers &lt;rob@bottled.codes&gt;:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u><=
/u><div><div><br></div><div><br></div><div>On Fri, Oct 24, 2025, at 08:34, =
Edmond Dantes wrote:</div><blockquote type=3D"cite" id=3D"m_-46079995749932=
15664qt"><div>Hello everyone,</div><div><br></div><div>In the TrueAsync RFC=
 4 thread, John Bafford raised a question about</div><div>parallelism.</div=
><div>I would like to share my thoughts and highlight this branch of the di=
scussion.</div><div><br></div><div># What is parallelism in the context of =
coroutines?</div><div>Parallelism for coroutines means the ability to execu=
te a coroutine in</div><div>one thread or another (but not simultaneously).=
</div><div>In this case, the Scheduler not only manages the execution order=
 of</div><div>coroutines but also decides which thread from the thread pool=
 should</div><div>be assigned to a coroutine.</div><div><br></div><div># Wh=
at is the problem?</div><div><br></div><div>If two different coroutines run=
 in separate threads and write to the</div><div>same memory region =E2=80=
=94 that is, to the same PHP object =E2=80=94 it will lead to</div><div>unp=
redictable consequences.</div><div><br></div><div>The issue is that PHP doe=
s not control memory access in such cases and</div><div>effectively allows =
the programmer to shoot themselves in the head.</div><div><br></div><div>Ho=
w can this be solved?</div><div><br></div><div>### Object transfer policy</=
div><div><br></div><div>The object transfer policy defines how a PHP object=
 can be safely</div><div>passed to another coroutine.</div><div>Possible tr=
ansfer methods:</div><div>1. Via parameters</div><div>2. Via context</div><=
div>3. Via channels</div><div><br></div><div>All these methods can be viewe=
d as variations of passing objects</div><div>through channels (similar to t=
he Erlang model =E2=80=94 no direct sharing).</div><div><br></div><div>The =
same policy applies to all methods.</div><div><br></div><div>An interface i=
s defined to guarantee an object=E2=80=99s =E2=80=9Cthread safety.=E2=80=9D=
 For</div><div>example, if a coroutine receives an object parameter without=
 this</div><div>interface, an error occurs.</div><div><br></div><div>In PHP=
, there are several possible ways to achieve thread safety:</div><div>1. **=
Ownership transfer**, as in C++/Rust =E2=80=94 the object leaves the</div><=
div>current scope and becomes owned by the coroutine.</div><div>2. **Proxy-=
based access**, using a special constructor that creates a</div><div>proxy =
object for access to the real one (similar to actors in Swift).</div><div>3=
. **Shared access** with a built-in mutex.</div><div><br></div><div>This ap=
proach requires minimal changes to the language syntax =E2=80=94 in</div><d=
iv>fact, none at all.</div><div>From a performance standpoint, it is perfec=
tly acceptable for PHP to</div><div>validate function parameters, so no sig=
nificant overhead should be</div><div>expected.</div><div><br></div><div>Th=
e main challenge of parallelism lies in making PHP=E2=80=99s internal state=
,</div><div>garbage collector, and memory manager thread-safe.</div><div><b=
r></div><div># How does this relate to TrueAsync?</div><div><br></div><div>=
At the moment, TrueAsync does not perform additional checks when</div><div>=
passing parameters to coroutines.</div><div>This is a problem =E2=80=94 bec=
ause once PHP introduces concurrency,</div><div>developers will start freel=
y using references (&amp;reference) and shared</div><div>objects.</div><div=
><br></div><div>When multitasking is later added to coroutines, it will bre=
ak existing</div><div>PHP code that has already been written.</div><div><br=
></div><div>Therefore, if PHP truly aims to become multithreaded, its memor=
y</div><div>ownership model must be carefully designed today.</div><div><br=
></div><div>---</div><div>Best Regards, Ed</div><div><br></div></blockquote=
><div><br></div><div>I=E2=80=99m not sure this is the place to discuss it, =
nor the time. But C# is cooperative multitasking on top of a VM which is pr=
eemptive multitasking. This basically allows you to run multithreaded witho=
ut worrying about =E2=80=9Cshooting yourself in the foot=E2=80=9D by access=
ing the same memory, most of the time. In other words, there is plenty of p=
rior art out there and ways to solve this problem. It doesn=E2=80=99t mean =
we need to solve it today. Trying to solve a problem that doesn=E2=80=99t c=
urrently exist and =E2=80=9Cmight=E2=80=9D be a problem later is exactly ho=
w you end up with overengineered solutions that never actually solve the pr=
oblem.=C2=A0</div><div><br></div><div id=3D"m_-4607999574993215664sig121229=
152">=E2=80=94 Rob</div></div></blockquote></div>

--000000000000730e760641e28691--