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