Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112921
MIME-Version: 1.0
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
In-Reply-To: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
Date: Mon, 18 Jan 2021 15:59:35 +0100
Message-ID: <CAEPJdumcsPXRxZCFDbFUBN+2JaEt0piYY0Cptu5pAShLStYBFA@mail.gmail.com>
To: Aaron Piotrowski <aaron@trowski.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000dd17c05b92df9c9"
Subject: Re: [PHP-DEV] [RFC] Fibers
From: kontakt@beberlei.de (Benjamin Eberlei)

--0000000000000dd17c05b92df9c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 17, 2020 at 5:30 PM 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
>

Hi Aaron,

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.

From 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.

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.

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?

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.


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000000dd17c05b92df9c9--