On Thu, Dec 4, 2014 at 1:17 PM, Julien Pauli <jpa...@php.net> wrote: > 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 >
Those are all solid ideas and I wouldn't go against them if proposed, I'm just a bit afraid that we end up with http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas on the ground of not being perfect or part of a bigger scheme while we don't have the resources to actually make those bigger schemes a reallity. Let see what the others think though. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
