Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79423
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAH-PCH5v-AyEiBRwZ=FCPkPk1GtyJEdk8k6FzFLRfZHbhuYbAg@mail.gmail.com>
References: <CAEPJdu=uW9D4Bz7hDhiGt=_qvWhAJfNfFwBJ0BKD77-L9rkgwQ@mail.gmail.com>
 <CAMUwpuTMgG=hJY4qVdst9zVgDTS7Y3QxSBFT80eBC_xSbWZFtA@mail.gmail.com> <CAH-PCH5v-AyEiBRwZ=FCPkPk1GtyJEdk8k6FzFLRfZHbhuYbAg@mail.gmail.com>
Date: Thu, 4 Dec 2014 13:17:35 +0100
Message-ID: <CAMUwpuQwu8BduvPi1oVWhP4dLXUiZM=SX3aT4u=4DcNcqPAyWA@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Turn gc_collect_cycles into a function pointer
From: jpauli@php.net (Julien Pauli)

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