Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70268
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <528CE64A.1020303@gmail.com>
References: <528CE64A.1020303@gmail.com>
Date: Thu, 21 Nov 2013 21:05:52 +0100
Message-ID: <CAH-PCH5RP1HRzC+qz94B862zrPt5O3x=U7MDvJJDPOJmAEkPjg@mail.gmail.com>
To: Terry Ellison <ellison.terry@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, Joe Watkins <krakjoe@php.net>
Content-Type: multipart/alternative; boundary=047d7b6dc0bcb82c7704ebb56ca7
Subject: Re: [PHP-DEV] Comments on non-unique naming convention for closures
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b6dc0bcb82c7704ebb56ca7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013.11.20. 17:42, "Terry Ellison" <ellison.terry@gmail.com> ezt =C3=ADrta:
>
> The following bugs relate to this discussion:
>
>     #64291 Indeterminate GC of evaled lambda function resources
>     #65915 Inconsistent results with require return value
>
> I don't want to discuss these or the specific fixes here, since I can
work up a fix and discuss them in the bugrep.  However,
> my one-sentence Q is "should we replace the naming convention for
closures with a truly unique one?"  What I would like is some feedback /
guidance / discussion on the general architectural issue which underlies
the reasons for these bugs occuring in the first place.
>
> *  The associated closure functions are compiled during the
INCLUDE_OR_EVAL opcode that included / eval'ed the originating PHP source,
and are named according to the convention "\0{closure}$name$addr" where the
name is the resolved filename of the source where the function was defined
and the addr is the absolute address of the function definition within the
memory resident copy of the source during the compilation process.  The
compilation creates an entry in the GC(function_table) for this function
>
> *  Closure objects are instantiated during the execution
ZEND_DECLARE_LAMBDA_FUNCTION opcode at runtime.  This handler invokes the
built-in CTOR for the closure bind the corresponding function,
>
> *  Closure objects are destroyed by the closure DTOR in line with the
usual PHP scoping rules.
>
> *  There is no specific deletion function for the GC(function_table)
entries other than normal request rundown, because the compiler and RTS
can't safely determine if a closure function will no longer be required for
further closure, e.g.
>
>     for ($array as $i) {
>         $f =3D function($x) { ... };
>         ...
>     }
>
> *  The "\0{closure}$name$addr" scheme does provide a sort of dirty reuse
in that if another function is compiled with the same filename and at the
same source address (which can happen for logically different variables due
to storage reuse), then the current implementation simply overwrites the
earlier function definition. Though the rationale for this isn't
documented, I assume that this is because it is _usually_ safe to assume
that the earlier copy is no longer required.  However, it is possible to
construct cases where this assumption is false -- especially as is the case
of OPcached functions where the name can persist for the life of the SMA
rather than just one request.
>
> What I am suggesting is that this convention should be changed for
something like "\0{closure}$name$ctime$index" or even just
"\0{closure}$uuid" using the standard UUID algo.  Reactions? Comments?
>
> The only side effect that I can see is that in circumstances where the
overwrite *does* replace stale functions then the function DTOR will no
longer be taking place leading a growth in the function table with the
associated memory overhead.
>
> Thanks for any feedback
> Terry
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Bumping the thread and ccing Joe as we were having a similar discussion
about the internal naming of the inner classes proposed by him.

--047d7b6dc0bcb82c7704ebb56ca7--