Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42453
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Fri, 2 Jan 2009 21:12:22 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1811359335.20090102211222@marcus-boerger.de>
To: Marcin Kurzyna <m.kurzyna@crystalpoint.pl>
CC: internals@lists.php.net
In-Reply-To: <87.E1.28540.1817E594@pb1.pair.com>
References: <87.E1.28540.1817E594@pb1.pair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Closures serialization
From: helly@php.net (Marcus Boerger)

Hello Marcin,

Friday, January 2, 2009, 8:56:41 PM, you wrote:

> Hello internals and a happy new year.

> I've been meaning to ask this for some time now: why aren't closures
> serializable? The only on-list discussion about this that i've found is:

> http://marc.info/?l=php-internals&m=119837318407795&w=2

> Personally i'd find serialization of closures very useful (think
> serializing of callback arrays, serialization of objects that acquired
> closure somewhere during execution, etc)

> Also i find that being unable to serialize closure introduces a slight 
> inconsistency. It was possible to serialize "is callable" type (plain 
> array/string) whereas now it's not always the case[1] so programmers 
> have to be aware of it when using some kind of "register callback" behavior.

> So to my question: why aren't closures serializable? Is it a design 
> choice or implementation issue?

> I've looked at both zend_closure.c (for closure implementation) and 
> var.c (for serialization) but didn't see anything that could suggest 
> either way.

> Now for some wild guessing: In the internals post mentioned above it's 
> stated that annonymous function name is along the lines of 
> hashfunction(__FILE__) and per_file_counter; i understand that it's 
> deterministic, and so if i were to serialize just this id (as sting) it 
> should be possible to track back to the actual code after 
> deserialization? i imagine that it would require (in simple terms) 
> getting the original file and "executing/assigning" n-th per_file 
> closure. It should be even simpler when done in the same request and/or 
> with opcode caches where just the id should be sufficient to get the 
> original opcodes and execute.

> I'll look some more into it myself but i'm not that fluent in C to 
> provide quality patch (not to mention zend api). I'd like to know your 
> opinion whether this could be implemented though.

You would need to provide a c level serialization that stores the $this
pointer (the easy part) and the zend_function member (not easy).  The
second part requires storing of all static variables, which again is
pretty easy but it also requires to store the function itself, which in
case of a user function probably only means the string but then at the
time of serialization you only have the compiled opcodes. So you would
need APC to serialize the opcodes, which is not yet implemented.
Alternatively you could save the implementation string somewhere. And
serialize that and compiling it upon  unserialization. If you're more
interested, c level serialization with multiple serialization inputs is
used for: SplObjectStorage::serialize() / unserialize().

marcus

> TIA
> Marcin Kurzyna

> [1] While it was possible to serialize an array of callbacks before it's 
> impossible with closures assigned, see example below:

> http://aquarion.hq.crystalpoint.pl/public/php-internals/closure-serialization.php





Best regards,
 Marcus