> > Have a different method `Fiber::suspendToScheduler(Resume $resume)` that would return the control to the Scheduler. >
That's exactly how it works. The RFC includes the method Async\wait() (Fiber::await() is nice), which hands control over to the Scheduler. At the PHP core level, there is an equivalent method used by all blocking functions. In other words, Fiber::suspend is not needed; instead, the Scheduler API is used. The only question is backward compatibility. If, for example, it is agreed that the necessary changes will be made in Revolt when this feature is released and we do not support the old behavior, then there is no problem. > > Maybe that is what we need: to be able to return control both to the parent fiber for custom logic that might be needed, and to the Scheduler so that the language would be concurrent. > 100% yes. > > As for userland event loops, like Revolt, I am not so sure they fit with the new language level async model. > Revolt can be adapted to this RFC by modifying the Driver module. I actually reviewed its code again today to assess the complexity of this change. It looks like it shouldn’t be difficult at all. The only problem arises with the code that has already been written and is publicly available. I know that the AMPHP stack is in use, so we need a *flow* that ensures a smooth transition. As I understand it, you believe that it’s better to introduce more radical changes and not be afraid of breaking old code. In that case, there are no questions at all. >