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