> On Jan 18, 2021, at 8:59 AM, Benjamin Eberlei <kont...@beberlei.de> wrote: > > 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.
Hi Benjamin, Sorry for the bit of a delay in replying. I’ve 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. > > 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? 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. > > 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. > I added a brief section under FAQs entitled "How are execution stacks swapped?”, 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
