On Sun, Mar 9, 2025, at 09:05, Edmond Dantes wrote:
> Good day, Alex.
>
> >
> > Can you please share a bit more details on how the Scheduler is implemented, to make sure
> > that I understand why this contradiction exists? Also with some examples, if possible.
> >
>
> ```php
> $fiber1 = new Fiber(function () {
> echo "Fiber 1 starts\n";
>
> $fiber2 = new Fiber(function () use (&$fiber1) {
> echo "Fiber 2 starts\n";
>
> Fiber::suspend(); // Suspend the inner fiber
> echo "Fiber 2 resumes\n";
>
> });
>
> });
> ```
>
>
> Yes, of course, let's try to look at this in more detail.
> Here is the classic code demonstrating how Fiber works. Fiber1
> creates Fiber2. When Fiber2 yields control, execution returns to
> Fiber1.
>
> Now, let's try to do the same thing with Fiber3. Inside Fiber2,
> we create Fiber3. Everything will work perfectly—Fiber3 will return
> control to Fiber2, and Fiber2 will return it to Fiber1—this
> forms a hierarchy.
>
>
> Now, imagine that we want to turn Fiber1 into a *Scheduler* while following these
> rules.
> To achieve this, we need to ensure that all Fiber instances are created from the
> *Scheduler*, so that control can always be properly returned.
>
> ```php
>
>
> class Scheduler {
> private array $queue = [];
>
> public function add(callable $task) {
> $fiber = new Fiber($task);
> $this->queue[] = $fiber;
> }
>
> public function run() {
> while (!empty($this->queue)) {
> $fiber = array_shift($this->queue);
>
> if ($fiber->isSuspended()) {
> $fiber->resume($this);
> }
> }
> }
>
> public function yield() {
> $fiber = Fiber::getCurrent();
> if ($fiber) {
> $this->queue[] = $fiber;
> Fiber::suspend();
> }
> }
> }
>
> $scheduler = new Scheduler();
>
> $scheduler->add(function (Scheduler $scheduler) {
> echo "Task 1 - Step 1\n";
> $scheduler->yield();
> echo "Task 1 - Step 2\n";
> });
>
> $scheduler->add(function (Scheduler $scheduler) {
> echo "Task 2 - Step 1\n";
> $scheduler->yield();
> echo "Task 2 - Step 2\n";
> });
>
> $scheduler->run();
>
> ```
>
> So, to successfully switch between Fibers:
>
> 1. A Fiber must return control to the *Scheduler*.
> 2. The *Scheduler* selects the next Fiber from the queue and switches to it.
> 3. That Fiber then returns control back to the *Scheduler* again.
>
>
> This algorithm has one drawback: *it requires two context switches instead of one*. We could
> switch *FiberX* to *FiberY* directly.
>
> Breaking the contract not only disrupts the code in this RFC but also affects Revolt's
> functionality. However, in the case of Revolt, you can say: *"If you use this library, follow
> the library's contracts and do not use Fiber directly."*
>
>
>
> But PHP is not just a library, it's a language that must remain consistent and cohesive.
>
>
> >
> > Reading the RFC initially, I though that the Scheduler is using fibers for everything
> > that runs.
> >
>
> Exactly.
>
>
> >
> > You mean that when one of the fibers started by the Scheduler is starting other fibers
> > they would usually await for them to finish, and that is a blocking operating that blocks also the
> > Scheduler?
> >
>
> When a *Fiber* from the *Scheduler* decides to create another *Fiber* and then tries to call
> blocking functions inside it, control can no longer return to the *Scheduler* from those functions.
>
> Of course, it would be possible to track the state and disable the concurrency mode flag when
> the user manually creates a *Fiber*. But… this wouldn't lead to anything good. Not only would
> it complicate the code, but it would also result in a mess with different behavior inside and
> outside of *Fiber*.
>
>
>
> This is even worse than calling *startScheduler*.
>
> The hierarchical switching rule is a *design flaw* that happened because a *low-level
> component* was introduced into the language as part of the implementation of a *higher-level
> component*. However, the high-level component is in *User-land*, while the low-level component is in
> *PHP core*.
>
> It's the same as implementing $this in OOP but requiring it to be explicitly
> passed in every method. This would lead to inconsistent behavior.
>
>
>
> So, this situation needs to be resolved one way or another.
>
> --
>
> Ed
>
Hi Ed,
If I remember correctly, the original implementation of Fibers were built in such a way that
extensions could create their own fiber types that were distinct from fibers but reused the context
switch code.
From the original RFC:
> An extension may still optionally provide their own custom fiber implementation, but an
> internal API would allow the extension to use the fiber implementation provided by PHP.
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).
Something to think about.
— Rob