castironpi-ng@comcast.net wrote:
I'm considering a workaround that performs GC in two steps. First, it requests the objects to drop their references that participate in the cycle. Then, it enqueues the decref'ed object for an unnested destruction.
I don't see how that solves anything. The problem is that the destructors might depend on other objects in the cycle that have already been deallocated. Deferring the calling of the destructors doesn't help with that. The only thing that will help is decoupling the destructor from the object being destroyed. You can do that now by storing a weak reference to the object with the destructor as a callback. But the destructor needs to be designed so that it can work without holding any reference to the object being destroyed, since it will no longer exist by the time the destructor is called. -- Greg