Re: threads, refcounting, XS, DESTROY

An alternative, perhaps uglier, approach is to share your objects and check threads::shared::_refcnt during DESTROYction.

POSIX::RT::Semaphore does this when run under threads, though a development branch did much the same CLONE counting as you detail above. It's all a lot of unfortunate bookkeeping, IMHO, to get the behavior exhibited by filehandles under threads, where the last dismissal in the last thread releases the underlying system resource.

Comment on Re: threads, refcounting, XS, DESTROY

Replies are listed 'Best First'.
Re^2: threads, refcounting, XS, DESTROY by Joost (Canon) on Aug 15, 2007 at 18:28 UTC
That may be uglier but it sounds like it would work a whole lot more robustly. Ps: is threads::shared::_refcnt() documented anywhere? update: I haven't found any documentation for this function, but a quick skimming of the source and tests for threads::shared indicates that `threads::shared::_refcnt()` returns the sum of the refcounts over all threads. very useful indeed. I'm going to experiment with this. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l]
Re^3: threads, refcounting, XS, DESTROY by Anonymous Monk on Aug 28, 2007 at 15:00 UTC
Unfortunately, it appears that _refcnt() does not always report the expected value during DESTROYction, meaning, IIUC, that final cleanup might be missed using this technique: http://www.nntp.perl.org/group/perl.ithreads/2007/08/msg1199.html Looks like it's back to user-defined bookkeeping...	[reply]