Front page | perl.perl5.porters |
Postings from September 2011
On Fri Sep 02 08:35:26 2011, jdhedden@cpan.org wrote: > Jerry wrote: > > threads::shared objects stored inside other > > threads::shared structures are not properly destroyed. > > When a threads::shared object is 'removed' from a > > threads::shared structure (e.g., a hash), the object's > > DESTROY method is not called. The attached script shows > > the cases when this occurs. > > Father Chrysostomos replied: > > Caused by this commit, but that doesn’t look like very > > useful information. Does the branch from which the > > threads changes were merged still exist, so I can try and > > find a description of the change (it added > > Perl_shared_object_destroy)? > > > > commit c07fbe7b8c333dbc876f7736f826d90e30b1a68b > > Author: Jerry D. Hedden <jdhedden@cpan.org> > > Date: Wed Dec 19 05:17:46 2007 -0500 > > > ... > > > > [ 32658] > > Subject: [PATCH] threads::shared 1.15 > > From: "Jerry D. Hedden" <jdhedden@cpan.org> > > When PL_destroyhook and Perl_shared_object_destroy were > added, the problem they were overcoming was that the > destruction of each threads::shared proxy was causing the > underlying shared object's DESTROY method to be called. The > fix provided a refcount check on the shared object so that > the DESTROY method was only called with the shared object > was no longer in use. > > The above works fine when delete() and pop() are used, > because a proxy is created for the stored shared object that > is being deleted (i.e., the value returned by the delete() > call), and when the proxy is destroyed, the object's DESTROY > method is called. > > However, when the stored shared object is 'removed' in some > other manner (e.g., setting the storage location to > 'undef'), there is no proxy involved, and hence DESTROY does > not get called for the object. > > I have no idea how to fix this problem, but I will at least > document it in the next release of threads::shared. > I wonder whether giving the shared object a destructor that calls back to whichever interpreter caused it would work. But how does one determine the calling interpreter? Does it matter in which thread the destructor runs? Isn’t it already effectively random for the cases in which the destructor does run? (Of course, destructors triggered the normal way would have to flag the shared object as having been destroyed already, perhaps by cursing it.)Thread Previous | Thread Next