Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129431
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com>
 <CAMW7n8DnE_M3MOOfH_4x9DOZyQyT6FCbhBtU+6tuDD3Rw0vzbQ@mail.gmail.com>
 <1402906904.784903.1763811759896@email.ionos.de> <2015208655.784984.1763811978476@email.ionos.de>
 <CAMW7n8D0=6hEPpZpGe2SrYKqgFqsDkPAjHBP4g5K45bFPaiNdw@mail.gmail.com>
 <980296152.1071.1763813573083@email.ionos.de> <CAMW7n8DXA501uGOY3952y8YhAJDVRrPYEiuw+Wzc5=oEciLVZQ@mail.gmail.com>
 <92865666.4510.1763818506332@email.ionos.de> <CAMW7n8AycfX4NMfjJ+GzFsPqRaSae-t7Cm3H5z8apRzXUgaVZw@mail.gmail.com>
 <329450798.8037.1763822426377@email.ionos.de> <CAMW7n8DTt2S_RfcyshERixed=qqyFUPEvWp_MpgpW_CvH3urXQ@mail.gmail.com>
 <CAMW7n8CUQxqh4_rTWQBcj+t17i5oW7x-V96FSkwZL85Z2pzrRw@mail.gmail.com>
 <CAB9bCb34cmu9=an9K4rubPSVEDwyWH-rMAVtTTYa3U-LA+GJ+A@mail.gmail.com>
 <CAMW7n8DM4MCP25gSLBbd3+Awzs2+p6Qs_jPgx1mk=RjSVe+iUw@mail.gmail.com>
 <9287c46c-bc63-4dd0-9792-0f9421959589@rwec.co.uk> <CAMW7n8AhbBawCBtfNJZ6XzFSvwhtZotfgBmb1O4CDZ+J2jxt2w@mail.gmail.com>
 <C766271D-EE7A-4727-8A7C-B117429768E5@rwec.co.uk>
In-Reply-To: <C766271D-EE7A-4727-8A7C-B117429768E5@rwec.co.uk>
Date: Mon, 24 Nov 2025 15:20:48 +0200
Message-ID: <CAMW7n8Bk+AhbXjg8QADFo=2k9qCE54DD68Hxkf2k_9J=EFboUQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello.

> Will Legacy Les see a side effect when he upgrades to SDK Susie's new asy=
nc library?

That=E2=80=99s the advantage of the idea. Legacy code doesn=E2=80=99t need =
to do anything.
Let=E2=80=99s assume all PHP code written before PHP9 is code that ran insi=
de
a single coroutine that was implicitly defined.

Let=E2=80=99s say we have a function myFun() with a static variable:

```php
<?php

function myFun(): void {
    static $counter =3D 0;

    $counter++;
    echo "Counter =3D {$counter}\n";
}

myFun(); // Counter =3D 1
myFun(); // Counter =3D 2
myFun(); // Counter =3D 3

But if you run this same function in another coroutine=E2=80=A6:

```php
function myFun(): void {
    static $counter =3D 0;
    $counter++;
    echo "counter =3D {$counter}\n";
}

awaitAll([
    spawn(myFun(...)), // Counter =3D 1
    spawn(myFun(...)), // Counter =3D 1
    spawn(myFun(...)), // Counter =3D 1
]);
```

A programmer working with coroutines will not be able to use static or
global variables to pass state.

They have only two ways to do it:
1. Function parameters
2. use to capture variables in a closure

This makes it impossible to accidentally shoot yourself in the foot. A
developer can still do something silly by explicitly passing objects
between coroutines, but now they are doing it consciously.

Although even here we can go further and create something similar to
ownership transfer of an object. In other words, an explicit semantics
that clearly specifies what to do with the object:

1. Should the object be **moved** between coroutines?
2. Should the object be **cloned**?
3. Is the object a special **shared** object that can be safely passed arou=
nd?

Such semantics makes coroutines thread-safe.

In other words, by designing a special parameter-passing semantics for
coroutines, we can create a perfect specification for coroutines that
can be run both in another thread and in the current one.
At the same time, the memory model becomes equivalent to Erlang=E2=80=99s
model, where there are no shared objects except for specific special
ones.

Such a change requires adding special **Shared** objects to the
language, which can be safely used across different threads. And
developers will no longer be able to use reference-based variables,
except within something like `SharedBox<T>`.
At the same time, implementing multi-threading support is not required
immediately. But once this capability is added, the language semantics
will already be fully prepared for it.

So props/cons:

1. Coroutines become safe execution containers that cannot
accidentally damage shared memory.
2. Old code requires no changes.
3. New coroutines cannot harm old code. And if parameter-passing
semantics are introduced, they won=E2=80=99t be able to harm it at all. PHP
will forbid a programmer from even trying to pass memory to another
coroutine just like that.
4. The language semantics make it possible to describe fully
thread-safe code, which can be added in the future at any time without
major changes.

**The cost:**
1. a developer must write a bit more code to work with shared objects
between coroutines.
2. In such a memory model, you cannot obtain the result of a
coroutine=E2=80=99s execution twice.
3. And this changes the philosophy of awaiting a coroutine: only one
coroutine can wait for another. However, this limitation has many
positive sides, because it greatly simplifies debugging.

Such a memory model is quite modern and yet not new. It is essentially
supported by Go, Erlang, and other next-generation languages.
Therefore, if PHP=E2=80=99s strategy is to eventually become a language wit=
h
parallelism while guaranteeing coroutine safety with respect to shared
memory, then this is the right path.
But I want to warn once again about the price that must be paid from
the developer=E2=80=99s point of view. A developer will no longer be able t=
o
use reference variables or pass objects between coroutines.

---
Ed