Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112969
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
In-Reply-To: <CAEPJdumcsPXRxZCFDbFUBN+2JaEt0piYY0Cptu5pAShLStYBFA@mail.gmail.com>
Date: Sat, 23 Jan 2021 13:11:29 -0600
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9BF046F2-4799-4CCD-A7F0-739A91C77E83@trowski.com>
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
 <CAEPJdumcsPXRxZCFDbFUBN+2JaEt0piYY0Cptu5pAShLStYBFA@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Subject: Re: [PHP-DEV] [RFC] Fibers
From: aaron@trowski.com (Aaron Piotrowski)


> On Jan 18, 2021, at 8:59 AM, Benjamin Eberlei <kontakt@beberlei.de> =
wrote:
>=20
> Hi Aaron,
>=20
> this is a very interesting and welcome piece of functionality. I have =
gone
> 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.
>=20
> =46rom my POV the effects on other extensions are the most important =
factor,
> you already have a section with that for Xdebug, Parallel, and pcov. =
But
> 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 =
the current fiber and uniquely identify each different fiber.

The internal API for this will need further discussion amongst the rest =
of 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.

>=20
> At the moment any PHP Profiler only has to manage a single stack of =
"open
> frames". With Fibers for each fiber a new stack must be opened.
>=20
> 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 =
executing 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 =
associated with the fiber.
The fiber ID is unique to the process and is never reused, so it can be =
used to determine which open stack frame to push a frame.

>=20
> Could you add a section to the RFC explaining how a switch between =
fibers
> works in terms of "the next" and "previous" zend_execute_data that is =
run?
> This  would also be interesting to understand how stack traces work, =
for
> example debug_print_backtrace.
>=20

I added a brief section under FAQs entitled "How are execution stacks =
swapped?=E2=80=9D, =
https://wiki.php.net/rfc/fibers#how_are_execution_stacks_swapped

Backtraces are currently limited to including only the currently =
executing fiber. It may be possible to include backtraces of fibers =
further down the execution stack, but I had issues when trying to =
implement this in the extension during shutdown due to stacks being =
freed. Something I think can be addressed if adding to core with the =
help of someone more familiar with how references to these stacks are =
kept and what should be modified in the functions generating backtraces.

Cheers,
Aaron Piotrowski