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