Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAH-PCH42Ptiv39-gQ7famvJNeGLcyvjcS7cSYtHO_pqA-bFh6g@mail.gmail.com>
References: <CAEPJdu=uW9D4Bz7hDhiGt=_qvWhAJfNfFwBJ0BKD77-L9rkgwQ@mail.gmail.com>
	<CAMUwpuTMgG=hJY4qVdst9zVgDTS7Y3QxSBFT80eBC_xSbWZFtA@mail.gmail.com>
	<CAH-PCH5v-AyEiBRwZ=FCPkPk1GtyJEdk8k6FzFLRfZHbhuYbAg@mail.gmail.com>
	<CAMUwpuQwu8BduvPi1oVWhP4dLXUiZM=SX3aT4u=4DcNcqPAyWA@mail.gmail.com>
	<CAH-PCH42Ptiv39-gQ7famvJNeGLcyvjcS7cSYtHO_pqA-bFh6g@mail.gmail.com>
Date: Thu, 4 Dec 2014 15:04:13 +0000
Message-ID: <CAGAGxbYGfkk4DOKDuooGstT=SAGxyw172ug2ybhucRRF6mj6yA@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, Benjamin Eberlei <kontakt@beberlei.de>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd9058efbf0950509654533
Subject: Re: [PHP-DEV] [RFC] Turn gc_collect_cycles into a function pointer
From: cw@daverandom.com (Chris Wright)

--047d7bd9058efbf0950509654533
Content-Type: text/plain; charset=UTF-8

On 4 December 2014 at 14:26, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> 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
> >
>
> 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

--047d7bd9058efbf0950509654533--