develooper 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 21:44
Subject:
[perl #98204] Shared objects not destoryed
Message ID:
rt-3.6.HEAD-31297-1315370653-775.98204-15-0@perl.org
On Tue Sep 06 18:02:19 2011, sprout wrote:
> The best way to attach a destructor to the shared SV would be to use
> custom free magic.

But that causes problems if our free magic function looks like this:

int
sharedsv_scalar_mg_free(pTHX_ SV *sv, MAGIC *mg)
{
    PERL_UNUSED_ARG(mg);
    /* We do not use CALLER_CONTEXT here, as whatever code herein triggered
       this free might still need its temps. */
    aTHX = caller_perl;
    sv_2mortal(S_sharedsv_new_private(aTHX_ sv));
    return (0);
}

We have to use sv_2mortal, rather than SvREFCNT_dec, as the latter could
cause a DESTROY method to be called while a lock is held.  So I use
sv_2mortal instead, but that means the sv’s refcount is increased.  But
sv_clear has no logic to handle magic giving an SV a new lease on life.
 It’ll just go ahead and free it anyway, probably causing crashes.

On the other hand, I could dissociate the private SV from the shared SV,
allowing the shared one to be freed.  I thought of that while writing
the previous paragraph.  Might as well leave this explanation here for
posterity. :-)

> 
> 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.

That’s my fallback if the above does not work.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About