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
