Posted: Sun Mar 26, 2006 4:19 pm
I am not sure thats possible...d11wtq wrote:I agree with Hockey here. From what I've read, including in the Zend documentation for writing extensions, the ZE has some advanced memory management features. Then again, what feyd mentioned about memory leaks in <place-name-of-some-big-library-here> rings a bell.
Extension writers are told to use Zend memory managment functions, which appear to be wrappers around crt functions, but with additional facilities, like GC.
If this is the case, a resource leak in an extension is likely caused by a developer using CRT functions instead of the Zend API, in which case no amount of unset() will release that memory.
Perhaps if the developer used Zend API memory managment functions, but didn't explicitly call efree() on memory, unset() might have knowledge of the memory, but GC would likely take care of that anyways.
Zend web site: "While an extension may, in theory, rely on ZE to free non-persistent memory automatically at the end of each page request, this is not recommended".
Basically what that tells me, is that ZE can take care of resources that extension developers don't free, but it's not as "clean" as explicitly freeing resources.
Now my question becomes, how does Zend handle memory clean up...using GC and reference counting...
when a reference count reaches zero, is efree() called or is it flagged as garbage and taken care of GC at script termination?
If this is the case, then calling unset() in PHP to correct an extension leak is pointless, cuz either way it happens at shutdown. If unset() does free memory immediately, then there might be some benefit to it.
http://ca3.php.net/manual/en/function.unset.php#56332
Not sure exactly what the guy in the post is saying, but it sounds like unset() frees the memory in the sense that it's no longer used by PHP, but it is still technically allocated and Zend just writes over top of it when new memory is needed.
This makes sense on one hand and on another no so much...
Cheers