I've been rewriting my embedded Python extension for PHP5 so that I
can take advantage of ZE2's spiffy object handler system. I've just
gotten most things working, but I noticed that my custom object
destructor is never being executed.
I ran the following through the debugger a few times:
$p = new Python('foo', 'Test');
And compared it to the execution of a "native" PHP class:
class Foo {}
$f = new Foo();
The difference appears to lay with the reference counts on the
resultant store object. With my Python class, an additional reference
is added to the store object, so zend_objects_store_del_ref() never
drops the reference count to zero, and the destructor is never
invoked.
It looks like this code from zend_execute.c is responsible for the
added reference:
if (PZVAL_IS_REF(value) && value->refcount > 0) {
ALLOC_ZVAL(variable_ptr);
*variable_ptr_ptr = variable_ptr;
*variable_ptr = *value;
zval_copy_ctor(variable_ptr);
variable_ptr->refcount=1;
break;
}
In my case, 'value' is a reference (PZVAL_IS_REF(value) == 1), and in
the case of the native PHP object, it isn't. zval_copy_ctor() calls
zend_objects_store_add_ref(), which increments the store object's
reference count.
Two questions:
Why is my object being treated as a reference while the native PHP
object is not?
'variable_ptr->refcount=1;' resets the reference count of the
variable's zval to 1, but the underlying _store_object's reference
count is still incremented. What will ever reclaim that reference on
the _store_object?
I'm still finding my way around the the "new" ZE2 way of doing things,
so please be gentle if the answers to these questions is obvious.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
