Mike Pomraning wrote: > I think it'd be a good idea formally to document/expose > threads::shared::_refcnt, though perhaps without the leading > underscore. > > When DESTROYing a share()d (and typically XS-backed) object that > represents some underlying system resource, one wants to > release/free/close/dismiss the system resource only on the final > DESTROY, regardless of thread. Perl's filehandles under ithreads > already behave like this without share()ing, but this behavior is > difficult to emulate with user-defined objects. ( See also > http://perlmonks.org/?node_id=632731 ) > > Of course, one can do this sort of bookkeeping one's self, but, AFAIK, > threads::shared is already doing the bookkeeping with _refcnt. > > Anyone have comments or a better way?
Jerry D. Hedden wrote: > Thanks for this info. For Object::InsideOut, I was tracking > thread usage for shared objects. I changed the code to > using _refcnt() (i.e., don't destroy if _refcnt($obj) > 1), > and it worked. It also reduced the code by about 3 dozen > lines of code. > > 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 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. (Now it may seem that the above construct seems inappropriate, but it does have a use: Not only can thread A and thread B both influence the same object, but if thread A changes the object, then thread B will see the new object as well.) 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. <shameless_self_promotion> Since Object::InsideOut supports XS-backed objects, I would recommend checking it out rather than "reinventing the wheel" as it were. </shameless_self_promotion> Since _refcnt can't be relied upon to help in DESTROY, is there any other utility in exposing it? If not, then I won't.
