[vtkusers] Breaking GC loops

[Kenneth Porter]

--On Friday, February 19, 2010 2:15 PM -0700 "Moreland, Kenneth" 
<kmorel at sandia.gov> wrote:

> Reference counting loops can be automatically detected and cleaned up by
> the VTK garbage collector if all the references in the loop are properly
> reported.  Details on reporting references to the garbage collector are
> documented in the vtkGarbageCollector class:
>
> http://www.vtk.org/doc/nightly/html/classvtkGarbageCollector.html#_details
>
> Keep in mind that in order for this to work, you have to be sure that all
> the references in the loop are reported.  If any are missing, the
> references can never be collected.

Very interesting. I'll have to try this out.

> As an alternative, you might want to consider using a vtkWeakPointer in
> place of one of the vtkSmartPointers.

This sounds like one needs to test for the weak pointer being null before 
dereferencing, unless one has good knowledge of actual usage that insures 
the pointer will be valid when dereferenced.

> As far as the render window/interactor goes, I would not look at that as
> an example.  That is an exceptional case that exists only because the
> order in which the two objects get destroyed matters.  They were also
> written before the garbage collector existed.  If they were to be
> rewritten today, I would expect that specialty code would not exist.

Which suggests that a workaround in the example is to destroy the style 
object before the window/interactor pair. This can be accomplished by 
insuring the style is instantiated only after the window/interactor are 
instantiated.

But part of the objective of the GC machinery is to decouple order of 
operations, so I consider this workaround to still be a hack.

So at this point I think defining ReportReferences to be the most promising 
solution. The only question is whether the involvement of the 
window/interactor in the relationship, having been written before the GC, 
defeats this functionality.