Front page | perl.perl5.porters |
Postings from September 2011
[perl #98204] Shared objects not destoryed
Thread Previous
|
Thread Next
From:
Father Chrysostomos via RT
Date:
September 6, 2011 18:02
Subject:
[perl #98204] Shared objects not destoryed
Message ID:
rt-3.6.HEAD-31297-1315357339-1454.98204-15-0@perl.org
On Fri Sep 02 23:57:52 2011, sprout wrote:
> 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?
I could store the calling interpreter in a static file-scoped variable
in shared.xs, instead of a local variable. Only code that obtains a
lock first could use that static variable, so I could call it
caller_perl (the name used by dTHXc) and omit the dTHXc declaration when
I want the file-scoped variable.
Is there any speed difference between file-scoped static variables and
local variables? If not, I could also remove every dTHXc that occurs
within a lock.
Is there anything wrong with that plan?
> 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.)
The best way to attach a destructor to the shared SV would be to use
custom free magic.
Then the free magic on the private SV could delete the magic before
lowering the refcnt if the shared SV has a refcnt of 1.
An alternative plan would be to push new proxy scalars on to the calling
context’s mortals stack in sharedsv_scalar_store and
sharedsv_array_mg_CLEAR, but that would require two iterations when
freeing any array or hash.
Thread Previous
|
Thread Next