Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuQwu8BduvPi1oVWhP4dLXUiZM=SX3aT4u=4DcNcqPAyWA@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>
Date: Thu, 4 Dec 2014 15:26:06 +0100
Message-ID: <CAH-PCH42Ptiv39-gQ7famvJNeGLcyvjcS7cSYtHO_pqA-bFh6g@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6046b4a3a23b050964bd6c
Subject: Re: [PHP-DEV] [RFC] Turn gc_collect_cycles into a function pointer
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b6046b4a3a23b050964bd6c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b6046b4a3a23b050964bd6c--