Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128941
Precedence: list
MIME-Version: 1.0
Date: Fri, 24 Oct 2025 09:34:26 +0300
Message-ID: <CAMW7n8CdUGSdXWnBM_ENCRaM6tqJta0n3sZF3y=WhFGdtajQbg@mail.gmail.com>
Subject: [PHP-DEV] PHP and parallelism
To: php internals <internals@lists.php.net>, John Bafford <jbafford@zort.net>, 
	Rob Landers <rob@bottled.codes>, Aaron Piotrowski <aaron@trowski.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

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 discussi=
on.

# 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 w=
ill 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 sa=
fety.=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 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.

The main challenge of parallelism lies in making PHP=E2=80=99s internal sta=
te,
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