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 7, 2011 05:40
Subject:
[perl #98204] Shared objects not destoryed
Message ID:
rt-3.6.HEAD-31297-1315399201-150.98204-15-0@perl.org
On Tue Sep 06 21:44:13 2011, sprout wrote:
> 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.

But that would mean copying the whole thing, which, while trivial for
scalars, is more complicated for hashes and arrays.

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

But that plan does not deal with ref refs.

Oh dear....


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