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 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. Matt On 9/15/05, Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Wed, Sep 07, 2005 at 02:37:33PM +0200, Leopold Toetsch wrote: > > > Parrot calls the "destroy" vtable function for all PMCs that have marked > > themselves with PObj_active_destroy_FLAG, when the object gets recycled > > due to GC *or* at program exit. > > If I have 2 objects in a self-referencing loop, what happens? > > A---+ > ^ | > | v > +---B > > Clearly mark and sweep can spot these things before the end of the world, > but how does all the destruction work? The GC has to call one PMC's destroy > first, so let's call that one A. > > A's destroy gets called. At this time A is pointing to a valid B object, > so it can make calls on B. > > At the end of this call, A is (presumably) in a consistent state, but not > a state consistent with having other methods called on it. But is its > vtable still active? Or is the vtable replaced with something else? > > Because what must come next is that B's destroy gets called. And as B still > has a pointer to A, B might (naïvely) try to make calls on A. > > Or are all objects that actively destroy themselves also expected to > actively swap their vtables to something safe? > > I'm not sure if this messy "call on a destructed object" scenario can occur > for non-active-destroy objects. > > Nicholas Clark > -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
