I have a wierd situation where A holds a reference to B, but B seems to be destroyed before A. I've ruled out the most obvious causes:
According to the perldocs (perlobj), an object is destroyed when the last reference to it is removed:
When the last reference to an object goes away, the object is automatically destroyed.
I would take that to mean that if object A is the sole holder of a reference to object B and A goes out of scope [ and has no package or in scope my variables holding a reference, i.e. refcount=0 ] then Perl would walk the object graph, first calling the destructor to A and then calling the destructors for each reference held solely by A. B cannot be destroyed before A because as long as A exists there is at least one reference to B.
This happens both on global destruction (exit) and controlled explicit destruction, i.e. undef $A.
In short, I'm stumped.
The platform is Perl 5.10.0 running on Debian Lenny. The Perl is threaded, but there is no explicit use of threads, so presumably A and B are on the same thread.
As ikegami helped me verify, despite my setting undef $A the object wasn't getting destroyed until the global destruction phase.
As Corion has confirmed (along with ikegami in the cb), during the global destruction phase Perl does not guarantee the order of destruction, so whether A gets destroyed before B or B before A is undetermined. And indeed, that was what I was observing: sometimes B would get destroyed first and sometimes A
The remaining question was why was destruction waiting until global destruction. The code boiled down to $A=SomeClass->new; undef $A so the reference count should have been 0. Perl destroys objects immediately when the ref count goes to 0 (also confirmed in cb and below).
Several suggested a hidden circularity that was keeping the ref count from actually going to 0. In the end the problem was not circularity, but canonization/memo-izing. To prevent duplicate creation of the same object a superclass was storing a hash of all previously created objects keyed by creation parameters. Unfortunately this hash was storing strong references when it should have been storing weak references. As a result, object A maintained a ref count of at least 1 until the canonizing hash was destroyed. As the canonizing hash was a package variable, it wasn't destroyed until the global destruction phase. So too object A. As expected, changing the canonizing hash so that it held weak references resolved the problem and allowed object A to be destroyed immediately after undef $A
Many thanks to the monks who helped me better test what was really happening and who spurred my problem solving thinking in new directions.
Update 1: added info about threading:
Update 2: Added solution
Update 3: clarified "goes out of scope" to response to anonymized user 468275's observation that "out of scope" is not necessarily synonymous with ref count = 0
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |