Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19544
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <434A2B43.7020608@vimio.com>
Date: Mon, 10 Oct 2005 10:50:11 +0200
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>
Cc: internals@lists.php.net
References: <4A.46.54476.C2272434@pb1.pair.com> <002801c5c8fe$b62d2ef0$6d561a44@lighthammer> <8F.35.54476.F96D4434@pb1.pair.com> <002f01c5caa1$da4f1b50$ad6c0646@lighthammer>
In-Reply-To: <002f01c5caa1$da4f1b50$ad6c0646@lighthammer>
Content-Type: multipart/mixed;
	boundary="------------020606000107020105020904"
Subject: Re: zval "passthrough"?
From: david.olsson@vimio.com (David Olsson)

--------------020606000107020105020904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> 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).

So that means that all the zval * I store in my map simply point to 
invalid memory once the request is completed? Well, that would explain 
some of the strange behaviour I have observed (such as string changing 
content between requests). The solution to this would be to allocate the 
zval struct using pemalloc and allocate memory for the data the zval 
(whatever type it is) uses with pemalloc as well?

>
> 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.
>
As far as I can tell, the APC extension doesn't use pemalloc but rather 
malloc. Furthermore, pemalloc simply seems to be a macro which uses 
malloc to allocate memory. This means that my memory allocations using 
c++ new should allocate persistent memory chunks. So the 
persistent/non-persistent memory issue doesn't explain why my std::map 
simply is empty. The fact that it contain zval pointers pointing to 
invalid memory I understand but I don't get why it gets emptied. Any ideas?

Best regards
David Olsson

--------------020606000107020105020904--