Front page | perl.perl5.porters |
Postings from September 2011
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.Thread Next