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