Front page | perl.perl5.porters |
Postings from September 2011
On Wed Sep 07 05:40:01 2011, sprout wrote:
> 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.
For hashes, because of the LAZYDEL optimisation, that would mean
continuously flipping back and forth between two values of aTHX during
hash iteration, which would be hard to get right.
>
> > > 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.
If we create a proxy for everything that is freed, even if it is not
blessed, then ref refs and nested aggregates will work. I think I’m
going to do it this way.
Thread Previous
|
Thread Next