Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129434
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>
In-Reply-To: <CAMW7n8Bk+AhbXjg8QADFo=2k9qCE54DD68Hxkf2k_9J=EFboUQ@mail.gmail.com>
Date: Mon, 24 Nov 2025 16:04:19 +0100
Message-ID: <CAEKnhAH9XphDrLfA-osOCK6O+sVYov_rNj8cTt3sG1AS2cA5LA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000163b820644587b95"
From: bukka@php.net (Jakub Zelenka)

--000000000000163b820644587b95
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Nov 24, 2025 at 2:23=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com>=
 wrote:

> 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?
>

This could be quite problematic for internal objects that might depend on
global that will switch.


> 2. Should the object be **cloned**?
>

Something like this should be done explicitly through channels otherwise it
would be quite strange semantically for users.


> 3. Is the object a special **shared** object that can be safely passed
> around?
>
>
I think it should be the only allowed case.


> 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. P=
HP
> 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 w=
ith
> 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=
 to
> use reference variables or pass objects between coroutines.
>
>
If we could make this work, then it could be a much better result as it
could open doors for true parallelisation. It will add more limitations in
terms of sharing code but I think it would be worth it.

I think the first thing for that would be good to look at is to make the
needed changes for TSRM which would be already useful for FrankenPHP :
https://github.com/php/frankenphp/discussions/1980 .

The context switches will likely become more expensive but should be still
cheaper than long IO. But obviously not idea if IO is available and switch
is not needed. The scheduler might need to be a bit smarter and try to
reduce switches though. I started writing IO ring library that is a thin
wrapper for liburing on Linux and it has compatibility layer for other
platforms using IO threads: https://github.com/libior/ior . This is still
limited and supports only basic ops but I plan to add more ops (including
epoll based ops). Also it will need Windows support.. But the advantage of
ring buffer is that it can significantly reduce syscalls and check multiple
completions in one go (it has already queue for them) so it could more
easily reduce number of switches (e.g. it can immediately get info whether
IO is available by going through all the completion events). I think it
should be a bit more flexible for scheduler. Anyway it's more a detail at
this stage but maybe something to think about later.

Kind regards,

Jakub

--000000000000163b820644587b95
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 24, 2025 at 2:23=
=E2=80=AFPM Edmond Dantes &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond=
.ht@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
A programmer working with coroutines will not be able to use static or<br>
global variables to pass state.<br>
<br>
They have only two ways to do it:<br>
1. Function parameters<br>
2. use to capture variables in a closure<br>
<br>
This makes it impossible to accidentally shoot yourself in the foot. A<br>
developer can still do something silly by explicitly passing objects<br>
between coroutines, but now they are doing it consciously.<br>
<br>
Although even here we can go further and create something similar to<br>
ownership transfer of an object. In other words, an explicit semantics<br>
that clearly specifies what to do with the object:<br>
<br>
1. Should the object be **moved** between coroutines?<br></blockquote><div>=
<br></div><div>This could be quite problematic for internal objects that mi=
ght depend on global that will switch.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
2. Should the object be **cloned**?<br></blockquote><div><br></div><div>Som=
ething like this should be done explicitly through channels otherwise it wo=
uld be quite strange semantically for users.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
3. Is the object a special **shared** object that can be safely passed arou=
nd?<br>
<br></blockquote><div><br></div><div>I think it should be the only allowed =
case.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
Such semantics makes coroutines thread-safe.<br>
<br>
In other words, by designing a special parameter-passing semantics for<br>
coroutines, we can create a perfect specification for coroutines that<br>
can be run both in another thread and in the current one.<br>
At the same time, the memory model becomes equivalent to Erlang=E2=80=99s<b=
r>
model, where there are no shared objects except for specific special<br>
ones.<br>
<br>
Such a change requires adding special **Shared** objects to the<br>
language, which can be safely used across different threads. And<br>
developers will no longer be able to use reference-based variables,<br>
except within something like `SharedBox&lt;T&gt;`.<br>
At the same time, implementing multi-threading support is not required<br>
immediately. But once this capability is added, the language semantics<br>
will already be fully prepared for it.<br>
<br>
So props/cons:<br>
<br>
1. Coroutines become safe execution containers that cannot<br>
accidentally damage shared memory.<br>
2. Old code requires no changes.<br>
3. New coroutines cannot harm old code. And if parameter-passing<br>
semantics are introduced, they won=E2=80=99t be able to harm it at all. PHP=
<br>
will forbid a programmer from even trying to pass memory to another<br>
coroutine just like that.<br>
4. The language semantics make it possible to describe fully<br>
thread-safe code, which can be added in the future at any time without<br>
major changes.<br>
<br>
**The cost:**<br>
1. a developer must write a bit more code to work with shared objects<br>
between coroutines.<br>
2. In such a memory model, you cannot obtain the result of a<br>
coroutine=E2=80=99s execution twice.<br>
3. And this changes the philosophy of awaiting a coroutine: only one<br>
coroutine can wait for another. However, this limitation has many<br>
positive sides, because it greatly simplifies debugging.<br>
<br>
Such a memory model is quite modern and yet not new. It is essentially<br>
supported by Go, Erlang, and other next-generation languages.<br>
Therefore, if PHP=E2=80=99s strategy is to eventually become a language wit=
h<br>
parallelism while guaranteeing coroutine safety with respect to shared<br>
memory, then this is the right path.<br>
But I want to warn once again about the price that must be paid from<br>
the developer=E2=80=99s point of view. A developer will no longer be able t=
o<br>
use reference variables or pass objects between coroutines.<br><br></blockq=
uote><div><br></div><div>If we could make this work, then it could be a muc=
h better result as it could open doors for true parallelisation. It will ad=
d more limitations in terms of sharing code but I think it would be worth i=
t.</div><div><br></div><div>I think the first thing for that would be good =
to look at is to make the needed changes for TSRM which would be already us=
eful for FrankenPHP :=C2=A0<a href=3D"https://github.com/php/frankenphp/dis=
cussions/1980">https://github.com/php/frankenphp/discussions/1980</a> .</di=
v><div><br></div><div>The context switches will likely become more expensiv=
e but should be still cheaper than long IO. But obviously not idea if IO is=
 available and switch is not needed. The scheduler might need to be a bit s=
marter and try to reduce switches though. I started writing IO ring library=
 that is a thin wrapper for liburing on Linux and it has compatibility laye=
r for other platforms using IO threads:=C2=A0<a href=3D"https://github.com/=
libior/ior">https://github.com/libior/ior</a> . This is still limited and s=
upports only basic ops but I plan to add more ops (including epoll based op=
s). Also it will need Windows support.. But the advantage of ring buffer is=
 that it can significantly reduce syscalls and check multiple completions i=
n one go (it has already queue for them) so it could more easily reduce num=
ber of switches (e.g. it can immediately get info whether IO is available b=
y going through all the completion events). I think it should be a bit more=
 flexible for scheduler. Anyway it&#39;s more a detail at this stage but ma=
ybe something to think about later.</div><div><br></div><div>Kind regards,<=
/div><div><br></div><div>Jakub</div></div></div>

--000000000000163b820644587b95--