Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113032
MIME-Version: 1.0
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
 <CAEPJdumcsPXRxZCFDbFUBN+2JaEt0piYY0Cptu5pAShLStYBFA@mail.gmail.com> <9BF046F2-4799-4CCD-A7F0-739A91C77E83@trowski.com>
In-Reply-To: <9BF046F2-4799-4CCD-A7F0-739A91C77E83@trowski.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Sun, 31 Jan 2021 10:29:36 -0700
Message-ID: <CAAKU0umwKnNe9kKzpk0tGZ7yWyOPdxjUHOXoU2cEiE3LZJbZPQ@mail.gmail.com>
To: Aaron Piotrowski <aaron@trowski.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Fibers
From: internals@lists.php.net ("Levi Morrison via internals")

On Sat, Jan 23, 2021 at 12:11 PM Aaron Piotrowski <aaron@trowski.com> wrote=
:
>
>
> > On Jan 18, 2021, at 8:59 AM, Benjamin Eberlei <kontakt@beberlei.de> wro=
te:
> >
> > Hi Aaron,
> >
> > this is a very interesting and welcome piece of functionality. I have g=
one
> > through the RFC a few times now, it have never thought about or worked =
with
> > fibers before, additional feedback will be forthcoming once I grasp the
> > details more.
> >
> > From my POV the effects on other extensions are the most important fact=
or,
> > you already have a section with that for Xdebug, Parallel, and pcov. Bu=
t
> > how does this affect Profilers that manage their own stack of frames,
> > either all function calls or specifically selected ones. I.e. xhprof,
> > tideways, datadog, newrelic and so on.
>
> Hi Benjamin,
>
> Sorry for the bit of a delay in replying. I=E2=80=99ve been busy the last=
 few days.
>
> Profilers that manage their own stack of frames will have to be modified =
to account for fibers. The extension currently provides an API to access th=
e current fiber and uniquely identify each different fiber.
>
> The internal API for this will need further discussion amongst the rest o=
f the internals contributors and hopefully the authors of those extensions.=
 I omitted any API for this from the RFC as it does not affect user code.
>
> >
> > At the moment any PHP Profiler only has to manage a single stack of "op=
en
> > frames". With Fibers for each fiber a new stack must be opened.
> >
> > Does an extension know what the "active" fiber is so that  from a
> > zend_execute_data I know on which stack of open frames I need to push a=
 new
> > frame?
>
> Four functions are currently provided for determining the current executi=
ng fiber.
>
> ```
> zend_fiber *zend_get_root_fiber()
> zend_fiber *zend_get_current_fiber()
> zend_long zend_fiber_get_id(zend_fiber *fiber)
> zend_long zend_fiber_get_current_id()
> ```
>
> These allow you to get the root and current fiber as well as the ID assoc=
iated with the fiber.
> The fiber ID is unique to the process and is never reused, so it can be u=
sed to determine which open stack frame to push a frame.

I think it would probably be advantageous to have an observer that
alerts interested parties when the fiber switches. This way we can
avoid querying the current fiber on every fcall.