Nick~ On 9/15/05, Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Thu, Sep 15, 2005 at 01:13:17PM -0400, Matt Fowles wrote: > > Nick~ > > > > Dan's plan was to do a topographic sort of the object tree to avoid > > this problem for non-loops and to break loops randomly. I believe he > > was even tempted to call rand in there just to make sure people didn't > > come to depend on a behavior... > > I agree with the use of rand. > > > I think it might be wise for us to make all the destruction calls > > before memory reclamation and replace each objects vtable with undef > > after its call. > > Setting to undef is in effect what Perl 5 does (although this can only > happen at global destruction time), because when a scalar is reclaimed, > its 24 flag bits are set to all zero, which is consistent with undef. > > I'm not sure that there is any other safe way, and it seems better that the > VM does it rather than rely on every PMC duplicating the code. Although the > idea of a PMC that has both finalize and destroy vtable entries clouds the > issue, because it would still need to see its vtable for destroy. > > I wonder if it makes sense for these to have an undef derivative that has > destroy and actually stores 1 item - the original vtable entry, and swaps > that vtable back in just to call destroy.
I disagree with the choice to have both finalize and destroy... If we must have both we could ensure that destroy is called immediately after finalize (but before VTABLE swap). Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
