Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.175 cause and error)
MIME-Version: 1.0
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, 11 Dec 2014 07:49:46 +0100
Message-ID: <CAEPJdu=mFg4aue1uhvc4Mr_Hv+yq3mGPNrmjhyZi4SS3cu4BVA@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043895778ffaca0509eb2e97
Subject: Re: [PHP-DEV] [RFC] Turn gc_collect_cycles into a function pointer
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d043895778ffaca0509eb2e97
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <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 Profiler=
s
>> >> > 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 fil=
e
>> >> 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 i=
n
>> >> the chain.
>> >> zend_module_entry could also benefit from refactoring to have a bette=
r
>> >> 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=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

--f46d043895778ffaca0509eb2e97--