Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128946
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 24 Oct 2025 11:19:57 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <0c852933-607a-4d50-94a8-641a3318f3c9@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8CMFst0DESarE0stVtaEKnaZzgW7iga7O+qBNH9t0cYMg@mail.gmail.com>
References: 
 <CAMW7n8CdUGSdXWnBM_ENCRaM6tqJta0n3sZF3y=WhFGdtajQbg@mail.gmail.com>
 <b7af2a5f-cffa-4668-99aa-495ed82b0cb0@app.fastmail.com>
 <CAMW7n8CMFst0DESarE0stVtaEKnaZzgW7iga7O+qBNH9t0cYMg@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP and parallelism
Content-Type: multipart/alternative;
 boundary=4a9e9630861745ac932ce018044abccf
From: rob@bottled.codes ("Rob Landers")

--4a9e9630861745ac932ce018044abccf
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Oct 24, 2025, at 09:30, Edmond Dantes wrote:
> But it's not a parallelism.=20
>=20
> =D0=BF=D1=82, 24 =D0=BE=D0=BA=D1=82. 2025=E2=80=AF=D0=B3., 09:43 Rob L=
anders <rob@bottled.codes>:
>> __
>>=20
>>=20
>> On Fri, Oct 24, 2025, at 08:34, Edmond Dantes wrote:
>>> Hello everyone,
>>>=20
>>> 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 d=
iscussion.
>>>=20
>>> # 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.
>>>=20
>>> # What is the problem?
>>>=20
>>> 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.
>>>=20
>>> The issue is that PHP does not control memory access in such cases a=
nd
>>> effectively allows the programmer to shoot themselves in the head.
>>>=20
>>> How can this be solved?
>>>=20
>>> ### Object transfer policy
>>>=20
>>> 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
>>>=20
>>> All these methods can be viewed as variations of passing objects
>>> through channels (similar to the Erlang model =E2=80=94 no direct sh=
aring).
>>>=20
>>> The same policy applies to all methods.
>>>=20
>>> An interface is defined to guarantee an object=E2=80=99s =E2=80=9Cth=
read safety.=E2=80=9D For
>>> example, if a coroutine receives an object parameter without this
>>> interface, an error occurs.
>>>=20
>>> In PHP, there are several possible ways to achieve thread safety:
>>> 1. **Ownership transfer**, as in C++/Rust =E2=80=94 the object leave=
s 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.
>>>=20
>>> This approach requires minimal changes to the language syntax =E2=80=
=94 in
>>> 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.
>>>=20
>>> The main challenge of parallelism lies in making PHP=E2=80=99s inter=
nal state,
>>> garbage collector, and memory manager thread-safe.
>>>=20
>>> # How does this relate to TrueAsync?
>>>=20
>>> 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.
>>>=20
>>> When multitasking is later added to coroutines, it will break existi=
ng
>>> PHP code that has already been written.
>>>=20
>>> Therefore, if PHP truly aims to become multithreaded, its memory
>>> ownership model must be carefully designed today.
>>>=20
>>> ---
>>> Best Regards, Ed
>>>=20
>>=20
>> I=E2=80=99m not sure this is the place to discuss it, nor the time. B=
ut C# is cooperative multitasking on top of a VM which is preemptive mul=
titasking. This basically allows you to run multithreaded without worryi=
ng about =E2=80=9Cshooting yourself in the foot=E2=80=9D by accessing th=
e same memory, most of the time. In other words, there is plenty of prio=
r 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=99=
t currently exist and =E2=80=9Cmight=E2=80=9D be a problem later is exac=
tly how you end up with overengineered solutions that never actually sol=
ve the problem.=20
>>=20
>> =E2=80=94 Rob

You=E2=80=99re technically right =E2=80=94 what you described isn=E2=80=99=
t parallelism, and it mixes a few distinct concerns: memory safety, owne=
rship, and object transfer, all under the label of =E2=80=9Cparallelism.=
=E2=80=9D But coroutines are explicitly cooperative. They don=E2=80=99t =
run in parallel unless a scheduler explicitly assigns them to threads, a=
nd we=E2=80=99re a long way from the VM being capable of that.

I=E2=80=99m also not sure why we=E2=80=99d even need an =E2=80=9Cobject =
transfer=E2=80=9D system. The entire point of threads is that memory is =
shared. If you want to pass an object to another thread, you just give i=
t a pointer =E2=80=94 full stop. The reason thread-safe extensions need =
to jump through hoops is TSRM: each thread gets its own VM context and t=
hread-local memory. That=E2=80=99s an engine-level design choice, not a =
missing userland feature. Opcache, for instance, could theoretically use=
 global memory with traditional locks instead of file locks in ZTS mode,=
 but that=E2=80=99s deep in engine territory =E2=80=94 far from anything=
 TrueAsync needs to consider right now.

So practically speaking, it=E2=80=99s not worth designing around this ye=
t. The engine would need massive adaptation before userland could safely=
 talk about =E2=80=9Cparallelism.=E2=80=9D

What you=E2=80=99re actually raising sounds more like concurrency =E2=80=
=94 specifically, managing mutable state across concurrent coroutines. T=
hat=E2=80=99s a valid topic, but concurrency control (locks, ownership s=
emantics, etc.) doesn=E2=80=99t belong in TrueAsync itself. If anything,=
 that would come later as a separate layer or RFC once the concurrency m=
odel stabilizes. It really should just be listed as Future Scope on that=
 RFC and dealt with if or when the RFC lands.

=E2=80=94 Rob
--4a9e9630861745ac932ce018044abccf
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 Fri, Oct 24, 2025, at 09:30, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"auto">But=
 it's not a parallelism.&nbsp;</div><div><br></div><div class=3D"qt-gmai=
l_quote qt-gmail_quote_container"><div dir=3D"ltr" class=3D"qt-gmail_att=
r">=D0=BF=D1=82, 24 =D0=BE=D0=BA=D1=82. 2025=E2=80=AF=D0=B3., 09:43 Rob =
Landers &lt;rob@bottled.codes&gt;:</div><blockquote class=3D"qt-gmail_qu=
ote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-l=
eft:0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204, 204, 204);padding-left:1ex;"><div><u></u><br></div><div><div>=
<br></div><div><br></div><div>On Fri, Oct 24, 2025, at 08:34, Edmond Dan=
tes wrote:</div><blockquote type=3D"cite" id=3D"qt-m_-460799957499321566=
4qt"><div>Hello everyone,</div><div><br></div><div>In the TrueAsync RFC =
4 thread, John Bafford raised a question about</div><div>parallelism.</d=
iv><div>I would like to share my thoughts and highlight this branch of t=
he discussion.</div><div><br></div><div># What is parallelism in the con=
text of coroutines?</div><div>Parallelism for coroutines means the abili=
ty to execute a coroutine in</div><div>one thread or another (but not si=
multaneously).</div><div>In this case, the Scheduler not only manages th=
e 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># What is the problem?</div><div><br></div><div>If tw=
o different coroutines run in separate threads and write to the</div><di=
v>same memory region =E2=80=94 that is, to the same PHP object =E2=80=94=
 it will lead to</div><div>unpredictable consequences.</div><div><br></d=
iv><div>The issue is that PHP does not control memory access in such cas=
es and</div><div>effectively allows the programmer to shoot themselves i=
n the head.</div><div><br></div><div>How can this be solved?</div><div><=
br></div><div>### Object transfer policy</div><div><br></div><div>The ob=
ject transfer policy defines how a PHP object can be safely</div><div>pa=
ssed to another coroutine.</div><div>Possible transfer methods:</div><di=
v>1. Via parameters</div><div>2. Via context</div><div>3. Via channels</=
div><div><br></div><div>All these methods can be viewed as variations of=
 passing objects</div><div>through channels (similar to the 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 is 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 th=
is</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 Swif=
t).</div><div>3. **Shared access** with a built-in mutex.</div><div><br>=
</div><div>This approach requires minimal changes to the language syntax=
 =E2=80=94 in</div><div>fact, none at all.</div><div>From a performance =
standpoint, it is perfectly acceptable for PHP to</div><div>validate fun=
ction parameters, so no significant overhead should be</div><div>expecte=
d.</div><div><br></div><div>The main challenge of parallelism lies in ma=
king PHP=E2=80=99s internal state,</div><div>garbage collector, and memo=
ry manager thread-safe.</div><div><br></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 coroutin=
es.</div><div>This is a problem =E2=80=94 because once PHP introduces co=
ncurrency,</div><div>developers will start freely using references (&amp=
;reference) and shared</div><div>objects.</div><div><br></div><div>When =
multitasking is later added to coroutines, it will break existing</div><=
div>PHP code that has already been written.</div><div><br></div><div>The=
refore, if PHP truly aims to become multithreaded, its memory</div><div>=
ownership model must be carefully designed today.</div><div><br></div><d=
iv>---</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 wi=
thout worrying about =E2=80=9Cshooting yourself in the foot=E2=80=9D by =
accessing the same memory, most of the time. In other words, there is pl=
enty of prior 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 does=
n=E2=80=99t currently exist and =E2=80=9Cmight=E2=80=9D be a problem lat=
er is exactly how you end up with overengineered solutions that never ac=
tually solve the problem.&nbsp;</div><div><br></div><div id=3D"qt-m_-460=
7999574993215664sig121229152">=E2=80=94 Rob</div></div></blockquote></di=
v></blockquote><div><br></div><div>You=E2=80=99re technically right =E2=80=
=94 what you described isn=E2=80=99t parallelism, and it mixes a few dis=
tinct concerns: memory safety, ownership, and object transfer, all under=
 the label of =E2=80=9Cparallelism.=E2=80=9D But coroutines are explicit=
ly cooperative. They don=E2=80=99t run in parallel unless a scheduler ex=
plicitly assigns them to threads, and we=E2=80=99re a long way from the =
VM being capable of that.<br></div><div><br></div><div>I=E2=80=99m also =
not sure why we=E2=80=99d even need an =E2=80=9Cobject transfer=E2=80=9D=
 system. The entire point of threads is that memory is shared. If you wa=
nt to pass an object to another thread, you just give it a pointer =E2=80=
=94 full stop. The reason thread-safe extensions need to jump through ho=
ops is TSRM: each thread gets its own VM context and thread-local memory=
. That=E2=80=99s an engine-level design choice, not a missing userland f=
eature. Opcache, for instance, could theoretically use global memory wit=
h traditional locks instead of file locks in ZTS mode, but that=E2=80=99=
s deep in engine territory =E2=80=94 far from anything TrueAsync needs t=
o consider right now.<br></div><div><br></div><div>So practically speaki=
ng, it=E2=80=99s not worth designing around this yet. The engine would n=
eed massive adaptation before userland could safely talk about =E2=80=9C=
parallelism.=E2=80=9D<br></div><div><br></div><div>What you=E2=80=99re a=
ctually raising sounds more like concurrency =E2=80=94 specifically, man=
aging mutable state across concurrent coroutines. That=E2=80=99s a valid=
 topic, but concurrency control (locks, ownership semantics, etc.) doesn=
=E2=80=99t belong in TrueAsync itself. If anything, that would come late=
r as a separate layer or RFC once the concurrency model stabilizes. It r=
eally should just be listed as Future Scope on that RFC and dealt with i=
f or when the RFC lands.</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob</div></body></html>
--4a9e9630861745ac932ce018044abccf--