Re: shared XS object destruction and _refcnt

On 8/21/07, Jerry D. Hedden <[email protected]> wrote:
> > I'll make a change to threads::shared to expose _refcnt() as
> > refcnt().  If anyone would like to suggest some description
> > for the POD, I'd be happy to consider it.  Thanks.
>
> 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
>

So... don't do that, then. :)  I don't explicitly share a
Thread::Queue and I don't explicitly share a Foo.  I trust these
modules to handle concurrency for me, and I turn to the pod for thread
safe usage guidelines.

> 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.

Are you saying that we may see "refcnt == 2", but not see "refcnt ==
1" during destruction?  Or that "refcnt == 1" might precede the
"refcnt == 2" DESTROY, though we are presumably lock()ing $self during
destruction?  Or something else?  (I'd be keen to see demonstration
code illustrating _refcnt's unreliability.)

> As such, the only way to "do it right" is to track thread
> usage for each object - which is exactly what I do in
> Object::InsideOut.

IMO, Dean's DESTROY_SHARED(), or equivalent, is the right way.  Short
of that, I'm looking for the lightest kludge.

Regards,
Mike
--
cat: .signature:  Too many references: cannot splice
panic