> You didn't understand what I'm saying. If we were to use emalloc/efree > (which we don't but we should if possible) and if we wouldn't replace them > with malloc/free on RSHUTDOWN, then some other Apache module which handles > the next request (mod_perl for example) would call our emalloc/efree. As > the memory manager wouldn't be initialized this would most likely crash.
But it always uses the persistent flag, so where is the memory manager issue? pemalloc(foo,1) is going to map straight to malloc(foo) is it not?
The way ext/pcre works is that it uses emalloc/efree for the non-persistent allocs directly but it registers pemalloc/pefree for the persistent memory handling. The correct fix here is to just use malloc/free for the persistent stuff.
Never mind. I don't feel like explaining myself a thousand times :) If you'd have read what I wrote you would have seen that I wasn't saying that we're using emalloc/efree (and thus the memory manager) today.
I was talking about the PCRE library and not the PCRE extension. But in any case, as PCRE is caching compiled regexes in between requests I don't think we can make the library use emalloc/efree.
Thus, it seems that the only option is to set the callbacks to malloc/free.
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
