Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112811
MIME-Version: 1.0
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
In-Reply-To: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
Date: Fri, 8 Jan 2021 01:03:56 -0800
Message-ID: <CAPrKfG6GdU5K=CcXSKCd9xpTmRZ_kK4v5QCPr8pxT5911+n+0Q@mail.gmail.com>
To: Aaron Piotrowski <aaron@trowski.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b8932b05b85fd6f0"
Subject: Re: [PHP-DEV] [RFC] Fibers
From: sarkedev@gmail.com (Peter Stalman)

--000000000000b8932b05b85fd6f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi again Aaron,

I've been playing around with this for a bit, and I have some more
questions. I see you recently changed how the `FiberScheduler` works,
making it `final` and adding some "is" functions to match it more to a
regular fiber.

Since the `FiberScheduler` is itself also a fiber, why does it need to be a
separate class?  Why did you choose to go this way and make it "special"
instead of not just making a regular fiber into a scheduler in userland.
Could you have two or more schedulers?  Could you get by without a
scheduler and call a fiber inside a fiber recursively?

Related to that, I noticed it was not possible to call `Fiber::this()` from
within the scheduler, why is that?  Is it not just another fiber?  Or is
this to prevent it from being passed to another scheduler?

Alternatively, going the other way, instead of making the scheduler a
unique class that needs to be passed around, why not go the more
"traditional" PHP route and pattern it after
`register_shutdown_function(callable $callback, mixed ...$args) : void`,
`spl_autoload_register(callable $autoload_function =3D ?, bool $throw =3D t=
rue,
bool $prepend =3D false) : bool`, and those type of functions?  After all,
isn't it just a callback too?  Something like
`register_fiber_scheduler(callable $callback) : void`?

This would remove the need for a special scheduler class and the need for
passing the scheduler back to the `Fiber::suspend()`.  Each `suspend()`
call would bubble up through the registered scheduler callbacks.  This
would allow competing schedulers to work nicer together, instead of one
scheduler having to finish before the higher up scheduler can run it's next
loop.

Either way, doesn't the fiber already know which scheduler it is in when it
suspends?

I think this would go along with simplifying it and keep the implementation
broad to allow for various userland implementations (as mentioned, such as
amphp and reactphp).  But it probably doesn't simplify the C
implementation...

Anyways, something like this?


    $fiber =3D Fiber::this();
    $callbacks =3D [
        fn() =3D> $fiber->resume("Test"),
    ];

    register_fiber_scheduler(function() use ($callbacks) {
        foreach ($callbacks as $callback) {
            $callback();
        }
    });

    $value =3D Fiber::suspend();

    echo "After resuming main fiber: ", $value, "\n"; // Output: After
resuming main fiber: Test


Btw, this is just me vomiting my thoughts, I don't know enough about fibers
to design it one way or the other, but I hope to understand it more as well
as give a few different perspectives on it.

Thanks,
Peter



On Thu, Dec 17, 2020 at 8:30 AM Aaron Piotrowski <aaron@trowski.com> wrote:

> Hello everyone!
>
> I would like to introduce an RFC for adding full-stack fibers to PHP:
> https://wiki.php.net/rfc/fibers
>
> Fibers are primarily used to implement green-threads or coroutines for
> asynchronous I/O. Fibers are similar to threads, except fibers exist with=
in
> a single thread and require cooperative scheduling of the fibers by the
> process. Since fibers do not require a full CPU context switch, they are
> lightweight and more performant than multi-processing or threading for
> awaiting I/O.
>
> An implementation as an extension is at https://github.com/amphp/ext-fibe=
r
>
> Fibers are a complex feature. The RFC contains many examples and links to
> code using fibers to help explain and demonstrate what is possible, howev=
er
> I=E2=80=99m certain many more questions and concerns will arise. Looking =
forward to
> feedback and discussion.
>
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000b8932b05b85fd6f0--