[PHP-DEV] Re: PHP True Async RFC Stage 3

Mailing Lists php.internals
1

Hello everyone.

I’ve been thinking about core developers these days, and I’m happy to see the PHP foundation growing, and more and more new developers arriving, eager to push PHP forward.

But at the same time, I have the feeling that some want to own it, are jealous, or are simply arrogant.

The subject of this topic is acclaimed by a good part of the community, the reactions are almost always positive, with lots of likes and comments, and some comments are even pessimistic, not because of the approach chosen by the author, but because of the ill will of the core developers.

Maybe if this proposal had come from a more respected developer, who had made more contributions, or I don’t know what the criteria for accepting it with open arms would be.

Seeing Edmond’s dedication, the great effort, to be ignored.

Maybe it really would have been possible to vote within 15 days, because it seems there were no objections.

A few years ago, a good developer arrived wanting to improve PHP, but what did they do? They treated him badly, they didn’t know how to lead. It’s typical of this list.

Seeing this topic still, I feel sad and realize how arrogant and toxic most of the inmates are.

2

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:

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’s truly an objective decision — not just because it’s
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’t been sitting idle :slight_smile:

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… and these
nuances are hard to predict. That’s why, before moving the RFC
forward, we need to see this API with our own eyes and test it
hands-on.

In the repository
GitHub - true-async/php-src at true-async-api you can see
what it looks like.
And here: php-src/Zend/zend_async_API.h at true-async-api · true-async/php-src · GitHub

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’s why I’ve now proposed including this **API** in **PHP 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’t be made perfect on
the first try. The best measure of truth is real-world usage in real
code and real scenarios.

That’s 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’s why I decided to do a full refactoring before drafting the RFC
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 — and that’s significant,
considering that a single request might involve 10–20 switches.

Next steps:
* A separate branch will include changes to PHP related to STREAMS,
DNS functions, and so on.
* That’s also where you can expect the RFC to be updated.

I hope my spoonful of jam was just in time :slight_smile:

Once again, thank you — and thanks to everyone who supports this project!

-- Ed

3

On Wed, May 28, 2025 at 2:01 PM carlos_silvaaaaa <carlos_silvaaaaa@proton.me> wrote:

Hello everyone.

I’ve been thinking about core developers these days, and I’m happy to see the PHP foundation growing, and more and more new developers arriving, eager to push PHP forward.

But at the same time, I have the feeling that some want to own it, are jealous, or are simply arrogant.

The subject of this topic is acclaimed by a good part of the community, the reactions are almost always positive, with lots of likes and comments, and some comments are even pessimistic, not because of the approach chosen by the author, but because of the ill will of the core developers.

Maybe if this proposal had come from a more respected developer, who had made more contributions, or I don’t know what the criteria for accepting it with open arms would be.

Seeing Edmond’s dedication, the great effort, to be ignored.

Maybe it really would have been possible to vote within 15 days, because it seems there were no objections.

A few years ago, a good developer arrived wanting to improve PHP, but what did they do? They treated him badly, they didn’t know how to lead. It’s typical of this list.

Seeing this topic still, I feel sad and realize how arrogant and toxic most of the inmates are.

I’m not one of the devs, just a user in the peanut gallery. (I’ve opened the PHP source code - it’s, uhm, intimidating). I don’t know what you’re referring to here and can’t comment to it. I can comment to at least the concept of adding async to PHP. In a word - why?

PHP scripts have a defined lifecycle and you’ll have to wait for any disk read ops or anything else you’d use a promise for to resolve anyway. JavaScript uses async to keep the code from locking up the browser while waiting on this sort of stuff - but PHP outputs an HTML file (usually) and that’s a one time event. And if you move to any context outside the webserver page request model why use PHP at all?

As a user I rather like not having to deal with async in PHP. While I can and do work with it in JavaScript it is by far the part of the language I dislike the most. If I’ve got to deal with concurrency and thread issues I’m writing the project in Golang or some other compiled language - not PHP - because if speed is that critical an interpreted scripting language is not the correct solution.