Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126783
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 16 Mar 2025 11:24:51 +0200
Message-ID: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
Subject: [PHP-DEV] PHP True Async RFC - Stage 2
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fb296f0630723e77"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000fb296f0630723e77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Good day, everyone. I hope you're doing well.

https://wiki.php.net/rfc/true_async

Here is a new version of the RFC dedicated to asynchrony.

Key differences from the previous version:

* The RFC is not based on Fiber; it introduces a separate class
representation for the asynchronous context.
* All low-level elements, including the Scheduler and Reactor, have been
removed from the RFC.
* The RFC does not include Future, Channel, or any other primitives, except
those directly related to the implementation of structured concurrency.

The new RFC proposes more significant changes than the previous one;
however, all of them are feasible for implementation.

I have also added PHP code examples to illustrate how it could look within
the API of this RFC.

I would like to make a few comments right away. In the end, the Kotlin
model lost, and the RFC includes an analysis of why this happened. The
model that won is based on the Actor approach, although, in reality, there
are no Actors, nor is there an assumption of implementing encapsulated
processes.

On an emotional level, the chosen model prevailed because it forces
developers to constantly think about how long coroutines will run and what
they should be synchronized with. This somewhat reminded me of Rust=E2=80=
=99s
approach to lifetime management.

Another advantage I liked is that there is no need for complex syntax like
in Kotlin, nor do we have to create separate entities like Supervisors and
so on. Everything is achieved through a simple API that is quite intuitive.

Of course, there are also downsides =E2=80=94 how could there not be? But
considering that PHP is a language for web server applications, these
trade-offs are acceptable.

I would like to once again thank everyone who participated in the previous
discussion. It was great!

--000000000000fb296f0630723e77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good day, everyone. I hope you&#39;re doing well.<div><br>=
</div><div><div><a href=3D"https://wiki.php.net/rfc/true_async">https://wik=
i.php.net/rfc/true_async</a></div></div><div><br></div><div>Here is a new v=
ersion of the RFC dedicated to asynchrony.<br><br>Key differences from the =
previous version:</div><div><br>* The RFC is not based on Fiber; it introdu=
ces a separate class representation for the asynchronous context.<br>* All =
low-level elements, including the Scheduler and Reactor, have been removed =
from the RFC.<br>* The RFC does not include Future, Channel, or any other p=
rimitives, except those directly related to the implementation of structure=
d concurrency.<br><br>The new RFC proposes more significant changes than th=
e previous one; however, all of them are feasible for implementation.<br><b=
r>I have also added PHP code examples to illustrate how it could look withi=
n the API of this RFC.<br></div><div><br></div><div>I would like to make a =
few comments right away. In the end, the Kotlin model lost, and the RFC inc=
ludes an analysis of why this happened. The model that won is based on the =
Actor approach, although, in reality, there are no Actors, nor is there an =
assumption of implementing encapsulated processes.<br><br>On an emotional l=
evel, the chosen model prevailed because it forces developers to constantly=
 think about how long coroutines will run and what they should be synchroni=
zed with. This somewhat reminded me of Rust=E2=80=99s approach to lifetime =
management.<br><br>Another advantage I liked is that there is no need for c=
omplex syntax like in Kotlin, nor do we have to create separate entities li=
ke Supervisors and so on. Everything is achieved through a simple API that =
is quite intuitive.<br><br>Of course, there are also downsides =E2=80=94 ho=
w could there not be? But considering that PHP is a language for web server=
 applications, these trade-offs are acceptable.<br></div><div><br></div><di=
v>I would like to once again thank everyone who participated in the previou=
s discussion. It was great!=C2=A0=C2=A0<br></div></div>

--000000000000fb296f0630723e77--