Re: [RFC] Turn gc_collect_cycles into a function pointer

On Thu, Dec 4, 2014 at 1:17 PM, Julien Pauli <jpauli@php.net> wrote: > On Thu, Dec 4, 2014 at 12:39 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: >> >> >> On Thu, Dec 4, 2014 at 11:53 AM, Julien Pauli <jpauli@php.net> wrote: >>> >>> On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei <kontakt@beberlei.de> >>> wrote: >>> > Good morning, >>> > >>> > This is just a very small change, I propose this RFC for discussion to >>> > turn >>> > the C function "gc_collect_cycles" into a pointer. >>> > >>> > https://wiki.php.net/rfc/gc_fn_pointer >>> > >>> > Composer's garbage collection optimization showed that PHP Profilers >>> > fail >>> > to capture the dynamics of GC and we need better hooks to make this >>> > possible. >>> >>> There are many other things that could be turned into function >>> pointers to allow extensions to hook. >>> Our hook strategy should be reviewed entirely. >>> >>> Not only GC. If you look at streams, many of them are not >>> overwritable, and some are, but they are missing from the headers file >>> so you may not overwrite them. >>> >>> I suggest we design a wider RFC for PHP7 about what we would be able >>> to hook, and what not (and what is the impact, because the more you >>> hook , the more complex it becomes about bad interactions). >>> >>> This may also include a refactoring in the zend_module_entry and the >>> zend_extension structs. Fe, zend_extension hooks about the op_array >>> could be reworked , I find the op_array_dtor_handler hook misplaced in >>> the chain. >>> zend_module_entry could also benefit from refactoring to have a better >>> knowing of other extensions, and a true dependency manager. >>> >> >> That sounds like a lot of work. >> +1 if somebody willing to champion that effort, but I wouldn't delay/discard >> this small improvement on the vague promise that maybe this will be solved >> as part of a bigger rfc. >> just my 2 cents ofc. > > Yep, but the problem in adding a new hook is that today its for > feature A, tomorrow it will be for feature B, etc... > There is a risk of lack of consistency between all the ideas, that's > why I myself did not propose any single idea in this way, but prefer > merging them and propose something more consistent. > We could benefit from a new major release to have a more global > hooking strategy. > Also, as this changes the ABI by publishing a new ZEND_API, we should > consider adding this in a major and not in a stable release (even > thought that doesnt break the ABI). > > I agree some ideas may represent more work than others (like a > dependency management system for extensions), however, big part of the > ideas is just about "what hook to move", "where to", "why" and > "what > hook to add" (and why). > > Also, having too many hooks can lead to many problems like extensions > incompatibility, something barely taken care of in our module API, but > which should as well be redesigned as it doesn't really work that > much. > > Julien.P For GC and any other function that would need to be overwritten, we may use zend_utility_functions. That would limit the number of exported symbols we publish. I don't know why zend_execute and zend_execute_internal are not part of it though. That would need a refactor to export zend_utility_function as global, and use it in any SAPI (it's actually local to main()). Dmitry, Laruence , any advice ? Julien.Pauli