>
> Maybe, we could create a different version of fibers ("managed fibers",
maybe?) distinct from the current implementation, with the idea to
deprecate them in PHP 10?
> Then, at least, the scheduler could always be running. If you are using
existing code that
> uses fibers, you can't use the new fibers but it will "just work" if you
aren't using the new fibers (since the scheduler will never pick up those
fibers).
>
Yes, that can be done. It would be good to maintain compatibility with
XDEBUG, but that needs to be investigated.
During our discussion, everything seems to be converging on the idea that
the changes introduced by the RFC into Fiber would be better moved to a
separate class. This would reduce confusion between the old and new
solutions. That way, developers wouldn't wonder why Fiber and coroutines
behave differently—they are simply different classes.
The new *Coroutine* class could have a different interface with new logic.
This sounds like an excellent solution.
The interface could look like this:
- *suspend* (or another clear name) – a method that explicitly hands
over execution to the *Scheduler*.
- *defer* – a handler that is called when the coroutine completes.
- *cancel* – a method to cancel the coroutine.
- *context* – a property that stores the execution context.
- *parent* (public property or getParent() method) – returns the parent
coroutine.
(*Just an example for now.*)
The *Scheduler* would be activated automatically when a coroutine is
created. If the index.php script reaches the end, the interpreter would
wait for the *Scheduler* to finish its work under the hood.
Do you like this approach?
---
Ed.
