Jerry D. Hedden wrote: > Turns out I had to revert this change. The trouble is the > following construct: > > my $obj :shared = Foo->new(); # Where Foo returns a shared object > > In this case, DESTROY (usually) gets an object with > refcnt == 2. To complicate matters further, the internal > order of destruction of Perl entities can cause > refcnt == 1 in this case. Therefore, refcnt cannot be > relied upon to control shared object destruction.
Mike Pomraning wrote: > Are you saying that we may see "refcnt == 2", but not see > "refcnt == 1" during destruction? Yes. DESTROY for the above construct gets the object with refcnt == 2 most of the time, but sometimes the refcnt is 1. > Or that "refcnt == 1" might precede the "refcnt == 2" > DESTROY No. > (I'd be keen to see demonstration code illustrating > _refcnt's unreliability.) Attached is the test code I wrote, however, you might not see the same results I do because the object destruction sequence is variable. Here's an example output: not ok 95 - # SKIP DESTROY: Baz_h 0 xxx 2 # Got : 2 # Expected : 1 # Failed test at line 356 not ok 96 - # SKIP DESTROY: Baz_s 0 86 2 # Got : 2 # Expected : 1 # Failed test at line 331 ok 97 - # SKIP DESTROY: Baz_a 0 123 1 The trailing number (2 or 1) is the refcnt seen in DESTROY. All should be 2, but you can see that the last on is 1. (The 'not ok' for 2 is because the hope was to control destruction only when refcnt is 1.) > IMO, Dean's DESTROY_SHARED(), or equivalent, is the right > way. The DESTROY_SHARED idea requires handling in the Perl interpreter which is beyond my knowledge to implement. > Short of that, I'm looking for the lightest kludge. Again, I put in a plug for Object::InsideOut which handles all these yucky details for you.
