PHP True Async RFC Stage 3 View as Markdown

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’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 :)

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
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/zend_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’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 :)

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

-- Ed

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.