> 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
