On Mon, Oct 27, 2025, at 18:53, Edmond Dantes wrote: > > I am not sure how feasible this is, but would there be a way to split the > > "async toggle" of IO operations off to its own PR/RFC? > > To me, that is by far the most important part of this RFC as that's the > > biggest blocker for wider async adoption, > > but I'm not sure how many layers are needed above it to make it possible to > > toggle in a safe fashion. > > Ah, I think I understand what you mean. > Yes, from an implementation standpoint, non-blocking behavior is > provided by the Scheduler API and Reactor API. These two APIs are > always available anywhere — in the core, extensions, and so on. > > However, this isn’t part of the RFC itself, as it belongs to > implementation details. Moreover, do you remember the first version of > the RFC? It had a function that explicitly started the Scheduler. So > indeed, in that first version PHP could be in two states: synchronous > and asynchronous. > > What’s the difference in this RFC? > PHP is **always** in an asynchronous state. Even when executing > index.php, you can think of it as running inside a coroutine. There’s > just a single coroutine, so no switching occurs (although an extension > could, for example, create another coroutine — which is perfectly > valid). > > You keep writing your code exactly as before. You don’t need to think > about PHP being “asynchronous” now. As long as you’re writing code > inside a single coroutine, you’re still writing synchronous code. > > -- Ed
As far as I understand, the only thing missing from php-src that would allow everything to be async is a Fiber scheduler. We already have tons of Fiber libraries out there ... but just no unified scheduler. If we had one of those, then making Fiber-aware i/o functions is "trivial" compared to implementing this async RFC. If we’re going to merge just a scheduler/reactor, it might make more sense to implement a Fiber scheduler than a completely new way of doing async. — Rob
