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
