Re: shared XS object destruction and _refcnt

Jerry D. Hedden wrote:
> 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?
> 
> 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.
> 

If the primary purpose of exposing this i/f is to get "real" destroy
logic, perhaps a more direct route is desirable ?
Either looking for a predefined method in the class
("DESTROY_SHARED()"), or registering a callback
to be called when refcount goes to zero ?
The callback would always be called in the context
of the thread which is about to cause refcount to drop to zero.

OTOH, I suppose thats a lot of work to avoid a simple
"if (refcnt() == 1) {}" in the DESTROY code. But it does
feel a bit more "natural".

Dean Arnold