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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
