On Thu, Dec 4, 2014 at 12:39 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > > On Thu, Dec 4, 2014 at 11:53 AM, Julien Pauli <jpa...@php.net> wrote: >> >> On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei <kont...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
