develooper Front page | perl.perl5.porters | Postings from September 2011

[perl #98204] Shared objects not destoryed

Thread Previous | Thread Next
Father Chrysostomos via RT
September 2, 2011 23:58
[perl #98204] Shared objects not destoryed
Message ID:
On Fri Sep 02 08:35:26 2011, 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 <>
> > Date:   Wed Dec 19 05:17:46 2007 -0500
> >
> ...
> >
> >    [ 32658]
> >    Subject: [PATCH] threads::shared 1.15
> >    From: "Jerry D. Hedden" <>
> 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About