On 4 December 2014 at 14:26, Ferenc Kovacs <tyr...@gmail.com> wrote: > 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. >
+1
