Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79427
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 209.85.212.169 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, 4 Dec 2014 16:01:36 +0100
Message-ID: <CAEPJdunOf4m2wGsu0WhpcA7Ma+FKPxaK5-aXE065_MXq55vG_w@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=f46d043895779e97e80509653c01
Subject: Re: [PHP-DEV] [RFC] Turn gc_collect_cycles into a function pointer
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d043895779e97e80509653c01
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
>

I agree, this change makes sense this way and is compatible to the way
hooks work right now. This change can be part of the grand refactoring
later on.

Refactoring the whole extension API is a bit time critical anyways, if we
won't find a champion for this in the next days/weeks then it won't happen
for 7.0 and then by definition (BC breaks) not for any version in 7.*
branch.

Expanding the scope of this too much will end up as failure.

>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

--f46d043895779e97e80509653c01--