[vtk-developers] Disturbing garbage collection behavior.
Brad King
brad.king at kitware.com
Thu Mar 3 09:04:14 EST 2005
Hi Ken,
Nice analysis. Please submit this as a bug report, assign it to me, and
I'll investigate your proposed solution.
Moreland, Kenneth wrote:
> Consider two VTK objects, A and B, that are garbage
> collected and point to each other. Furthermore, assume that the only
> reference to B is from A (whereas A has multiple references to it).
> Consider what happens when a method in A executes the following code:
>
> A->PointerToB->UnRegister(this);
> A->PointerToB = NULL;
>
> The intent of the code is obviously meant for A to drop its reference to
> B.
As you said this code is technically "wrong" according to the current
garbage collector implementation. The assumption is that all objects
have an invariant that each ivar either references a valid fully
constructed object or is NULL. This code violates that invariant.
This is actually an argument for using smart pointers more liberally.
If you look at the destructor of vtkSmartPointerBase you will see that
it already maintains this invariant using code similar to your
three-line correct example. That combined with its assignment operator
implementation will produce correct behavior for the simple line
A->SmartPointerToB = 0;
> I think the garbage collector can be corrected by maintaining a set of
> objects that are in the process of destruction. Whenever a link to an
> object in the process of destruction is encountered, it can be ignored
> with the assumption that it is about to be obliterated as in the code
> above. I can think of no down side to this approach.
This will probably work. We can then relax the assumption of the above
mentioned invariant and this relaxation can be considered a feature of
the garbage collector. I'll investigate finding a smooth integration
into the current implementation.
-Brad
More information about the vtk-developers
mailing list