Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.43 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
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 14:56:15 +0100
Message-ID: <CAMUwpuRsWRX+Em5HfEJDNLgq0-1D6GoCrRP2Q5eLeFvjVe=8Cg@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 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




For GC and any other function that would need to be overwritten, we
may use zend_utility_functions.
That would limit the number of exported symbols we publish.

I don't know why zend_execute and zend_execute_internal are not part
of it though.

That would need a refactor to export zend_utility_function as global,
and use it in any SAPI (it's actually local to main()).

Dmitry, Laruence , any advice ?

Julien.Pauli