I updated the RFC to include a paragraph on this. The change should be included as-is and then be part of a potential refactoring, should one happen.
On Thu, Dec 4, 2014 at 3:26 PM, 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. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
