Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128942
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 24 Oct 2025 08:42:58 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>,
 "php internals" <internals@lists.php.net>,
 "John Bafford" <jbafford@zort.net>, "Aaron Piotrowski" <aaron@trowski.com>
Message-ID: <b7af2a5f-cffa-4668-99aa-495ed82b0cb0@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8CdUGSdXWnBM_ENCRaM6tqJta0n3sZF3y=WhFGdtajQbg@mail.gmail.com>
References: 
 <CAMW7n8CdUGSdXWnBM_ENCRaM6tqJta0n3sZF3y=WhFGdtajQbg@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP and parallelism
Content-Type: multipart/alternative;
 boundary=fd5c8e7defbe4d90bc47a9a487d38819
From: rob@bottled.codes ("Rob Landers")

--fd5c8e7defbe4d90bc47a9a487d38819
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



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 dis=
cussion.
>=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 and
> 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 shar=
ing).
>=20
> The same policy applies to all methods.
>=20
> An interface is defined to guarantee an object=E2=80=99s =E2=80=9Cthre=
ad 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 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.
>=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 interna=
l 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 existing
> 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

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 multit=
asking. This basically allows you to run multithreaded without worrying =
about =E2=80=9Cshooting yourself in the foot=E2=80=9D by accessing the s=
ame memory, most of the time. In other words, there is plenty of prior a=
rt 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=
 how you end up with overengineered solutions that never actually solve =
the problem.=20

=E2=80=94 Rob
--fd5c8e7defbe4d90bc47a9a487d38819
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 08:34, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hello everyone,<=
/div><div><br></div><div>In the TrueAsync RFC 4 thread, John Bafford rai=
sed a question about</div><div>parallelism.</div><div>I would like to sh=
are my thoughts and highlight this branch of the discussion.</div><div><=
br></div><div># What is parallelism in the context of coroutines?</div><=
div>Parallelism for coroutines means the ability to execute a coroutine =
in</div><div>one thread or another (but not simultaneously).</div><div>I=
n this case, the Scheduler not only manages the execution order of</div>=
<div>coroutines but also decides which thread from the thread pool shoul=
d</div><div>be assigned to a coroutine.</div><div><br></div><div># What =
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>=
unpredictable consequences.</div><div><br></div><div>The issue is that P=
HP does not control memory access in such cases and</div><div>effectivel=
y allows the programmer to shoot themselves in the head.</div><div><br><=
/div><div>How can this be solved?</div><div><br></div><div>### Object tr=
ansfer policy</div><div><br></div><div>The object transfer policy define=
s how a PHP object can be safely</div><div>passed to another coroutine.<=
/div><div>Possible transfer methods:</div><div>1. Via parameters</div><d=
iv>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 sharin=
g).</div><div><br></div><div>The same policy applies to all methods.</di=
v><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 corout=
ine receives an object parameter without this</div><div>interface, an er=
ror occurs.</div><div><br></div><div>In PHP, there are several possible =
ways to achieve thread safety:</div><div>1. **Ownership transfer**, as i=
n C++/Rust =E2=80=94 the object leaves the</div><div>current scope and b=
ecomes owned by the coroutine.</div><div>2. **Proxy-based access**, usin=
g 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 acc=
ess** with a built-in mutex.</div><div><br></div><div>This approach requ=
ires 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 a=
cceptable for PHP to</div><div>validate function parameters, so no signi=
ficant overhead should be</div><div>expected.</div><div><br></div><div>T=
he main challenge of parallelism lies in making PHP=E2=80=99s internal s=
tate,</div><div>garbage collector, and memory 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 wh=
en</div><div>passing parameters to coroutines.</div><div>This is a probl=
em =E2=80=94 because once PHP introduces concurrency,</div><div>develope=
rs will start freely using references (&amp;reference) and shared</div><=
div>objects.</div><div><br></div><div>When multitasking is later added t=
o coroutines, it will break existing</div><div>PHP code that has already=
 been written.</div><div><br></div><div>Therefore, if PHP truly aims to =
become multithreaded, its memory</div><div>ownership model must be caref=
ully 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 no=
t sure this is the place to discuss it, nor the time. But C# is cooperat=
ive multitasking on top of a VM which is preemptive multitasking. This b=
asically allows you to run multithreaded without worrying about =E2=80=9C=
shooting yourself in the foot=E2=80=9D by accessing the same memory, mos=
t of the time. In other words, there is plenty of prior art out there an=
d ways to solve this problem. It doesn=E2=80=99t mean we need to solve i=
t today. Trying 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 actually solve the problem.&nb=
sp;</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></bo=
dy></html>
--fd5c8e7defbe4d90bc47a9a487d38819--