Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127502
Precedence: bulk
MIME-Version: 1.0
References: <5Q_DNeA5NK_aXkyoWmQZKVdlml8KLTwm9jeP7Y2vqQwZ8hxhfIIQdwF4-2Ra48E4Sob1aMXL2Hp-boAIZbQrSsfgNCNmm4LDduryOnC7K0Y=@proton.me>
In-Reply-To: <5Q_DNeA5NK_aXkyoWmQZKVdlml8KLTwm9jeP7Y2vqQwZ8hxhfIIQdwF4-2Ra48E4Sob1aMXL2Hp-boAIZbQrSsfgNCNmm4LDduryOnC7K0Y=@proton.me>
Date: Thu, 29 May 2025 10:51:19 +0300
Message-ID: <CAMW7n8AY5q9n4Nx_H7qiEGyrt3ghNvQPnn7Spb5BE0XAkXAtyw@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 3
To: carlos_silvaaaaa <carlos_silvaaaaa@proton.me>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello, Carlos!

Thank you for your support.
I feel like I should add a bit of jam to this story and share some news.

When I set the two-week limit for the vote, Roman Pronskiy reached out
to me almost immediately and offered direct contact with PHP CORE.
I received maximum support and valuable advice from him. It gave me
the opportunity to ask difficult questions about the PHP core.

We now have a cozy little chat with PHP CORE members, for which I'm
very grateful.

Jakub created a separate project on GitHub:
https://github.com/true-async/php-async
where you can follow the development process live.

Together with the PHP Team, a development plan for the **True Async**
project was agreed upon. In broad terms, it goes as follows:

* The current RFC will be simplified as much as possible to make it
easier to pass. New syntax should be discussed closer to future
versions of PHP (likely 9.0). If needed, I can explain why this is the
case, but it=E2=80=99s truly an objective decision =E2=80=94 not just becau=
se it=E2=80=99s
hard to vote on, but also because `PHP` has consistency issues with
its syntax.
* We aim for an implementation where asynchrony and the PHP core are
as decoupled from each other as possible.
* Larry Garfield proposed the idea of long-term development planning.
I hope it gains traction.

As you can see, we haven=E2=80=99t been sitting idle :)

Now, regarding the technical details.

I like the idea of separating the **True Async** implementation from
the core as much as possible, leaving only a thin API in the core.
This is a complex architectural task with many nuances=E2=80=A6 and these
nuances are hard to predict. That=E2=80=99s why, before moving the RFC
forward, we need to see this API with our own eyes and test it
hands-on.

In the repository
https://github.com/true-async/php-src/tree/true-async-api you can see
what it looks like.
And here: https://github.com/true-async/php-src/blob/true-async-api/Zend/ze=
nd_async_API.h

Almost everything has been extracted from the core (except for the
Cancellation exception). That includes even the coroutine
implementation.
Once this API becomes available, PHP will no longer have limitations
for other similar implementations.

That=E2=80=99s why I=E2=80=99ve now proposed including this **API** in **PH=
P 8.5**. If
that happens, developers will be able to use asynchronous `PHP` in
experimental mode.

The experimental mode is extremely important for the project.
A large and complex feature like asynchrony can=E2=80=99t be made perfect o=
n
the first try. The best measure of truth is real-world usage in real
code and real scenarios.

That=E2=80=99s why early access to the project, before making it standard, =
is
so crucial.
My development experience (which includes plenty of funny stories)
tells me this is the most reliable path to success.

That=E2=80=99s why I decided to do a full refactoring before drafting the R=
FC
again. And the initial part of the refactoring is already complete. I
can already say: IT WAS WORTH IT.

* The hacks around starting the Scheduler have been removed.
* A modern Scheduler mechanism has been implemented, which cuts the
number of context switches in half =E2=80=94 and that=E2=80=99s significant=
,
considering that a single request might involve 10=E2=80=9320 switches.

Next steps:
* A separate branch will include changes to PHP related to STREAMS,
DNS functions, and so on.
* That=E2=80=99s also where you can expect the RFC to be updated.

I hope my spoonful of jam was just in time :)

Once again, thank you =E2=80=94 and thanks to everyone who supports this pr=
oject!

-- Ed