Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19452
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <002f01c5caa1$da4f1b50$ad6c0646@lighthammer>
To: "David Olsson" <david.olsson@vimio.com>
Cc: <internals@lists.php.net>
References: <4A.46.54476.C2272434@pb1.pair.com> <002801c5c8fe$b62d2ef0$6d561a44@lighthammer> <8F.35.54476.F96D4434@pb1.pair.com>
Date: Thu, 6 Oct 2005 11:14:48 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: zval "passthrough"?
From: pollita@php.net ("Sara Golemon")

> Thanks! That was very useful information. Had to go with the #3a solution 
> as I need to be compatible with PHP4.
>
> I still have some problems with my extension though. The extension 
> maintains a module global C++ std::map allocated in my MINIT function and 
> deallocated in my MSHUTDOWN function. This map stores some zval * added to 
> the map like this:
>
Normal userspace variables (zvals) are allocated "non-persistently".  This 
means that, for example, creating a string variable consists of emalloc() 
calls:

foo = emalloc(sizeof(zval));
foo->value.str.val = emalloc(sizeof("bar"));

emalloc()'d pointers are forcibly freed between requests (as part of Zend's 
garbage collection), so even though you've taken care of all the other bits 
or placing the zval* into your map in regards to reference counting and 
creating a true copy, the zval itself is allocated non-persistently and will 
be quietly killed by the engine at the end of your request. (Well, no so 
quietly if you have --enable-debug turned on).

In order to hold a zval between requests you'll have to make a persistent 
copy of it (using pemalloc() which, I'm afraid, is a bit more complicated 
than it sounds).  Take a look at apc_store() and apc_fetch() which 
do...well....pretty much what you're talking about here.

> Currently i allocate memory for the map with new instead of emalloc but 
> should that make any difference (except for larger risks for memory 
> leaks)?
>
new will end up using malloc() which is what a persistent allocation would 
use anyway.  You actually *can't* use emalloc() in your MINIT code because 
emalloc() is only to be used within a request (which you're not inside of at 
that point).

-Sara