Front page | perl.perl5.porters |
Postings from November 2003
On Sat, 15 Nov 2003, Elizabeth Mattijsen wrote: > I guess the question is: can threads::shared::_refcnt be considered > part of the threads API? I hope it lingers until shared objects are DESTROYed only once; that'd solve a lot of problems in a very natural way. :-) (I expect an unshared object to be multiply DESTROYed -- it's copied, after all. When I share an object, however, I'm putting forth one single thing for everybody to play with, and would like it to suffer destruction only once.) > In any case, the problem is specific for unshared object really. Well, specifically for objects unshared from Perl's perspective but with an underlying shared resource or operation (a socket shutdown, XS-alloc'd memory, etc.). Flipping on share() unfortunately doesn't take care of the problem, but it does allow manual _refcount-checking/destruction as a workaround. > Objects from modules that don't expect to have multiple DESTROY's > called on their objects Perl filehandles are interesting in this context -- they behave like I'd expect a shared object to behave. If I open($fh, ...) and undef($fh) in a different thread, the underlying fd sticks around until the last $fh reference evaporates. I believe this is b/c Perl essentially does CLONE/fd bookkeeping under the hood for file-ish things -- one approach suggested in this thread for the general problem. Not as natural, IMHO, as expecting a single object to be destroyed once. Apologies -- I know that patches are preferred to plaintive posts, but my own attempts (a shoehorned a PL_dtorhook/shared.xs gambit) haven't been pretty. -MikeThread Previous | Thread Next