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
