Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129437
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> <CAMW7n8Bk+AhbXjg8QADFo=2k9qCE54DD68Hxkf2k_9J=EFboUQ@mail.gmail.com>
 <CAEKnhAH9XphDrLfA-osOCK6O+sVYov_rNj8cTt3sG1AS2cA5LA@mail.gmail.com>
In-Reply-To: <CAEKnhAH9XphDrLfA-osOCK6O+sVYov_rNj8cTt3sG1AS2cA5LA@mail.gmail.com>
Date: Mon, 24 Nov 2025 18:32:16 +0200
Message-ID: <CAMW7n8DSYXfkgoamN2b9Eo9TeUDVwYyPpZAt6VemiC2y0W+qgQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Jakub Zelenka <bukka@php.net>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello

> This could be quite problematic for internal objects that might depend on=
 global that will switch.
Yes, this will require changes to the PHP Engine, and we will have to
determine their scope.

> Something like this should be done explicitly through channels otherwise =
it would be quite strange semantically for users.

Yes, exactly, channels are an excellent way to explicitly pass objects
between coroutines.
But thanks to the ownership policy, the developer gains the ability to
explicitly clone an object before passing it.

Example:
```php
function x(own object $y): void
{

}

$var =3D new Obj();
$var2 =3D $var;

x($var); // error: can't move object to x, because refcount > 1
x(clone $var); // yes it's possible

```

> I think it should be the only allowed case.
Of course

> The context switches will likely become more expensive but should be stil=
l cheaper than long IO.

I don=E2=80=99t know. To answer this question, we need to write code. But I
hope it=E2=80=99s possible to find an optimization that has almost no
performance impact.
To solve this problem, one important change is needed: removing static
var from opcodes.
This would make it possible to share PHP opcodes between N threads as
a readonly structure. I can=E2=80=99t say how feasible this task is. But if=
 it
is feasible, it opens the door to the third memory model (shared
nothing).
But as you understand, this approach provides the maximum possible
level of protection.

> This is still limited and supports only basic ops but I plan to add more =
ops
Yes, this will give additional capabilities for the Reactor.
I can see that libUV isn=E2=80=99t in much of a hurry to implement them.

---
Ed