>
> 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.

>

Reply via email to