[vtkusers] Memory Management

[Gerald Dalley]

I've been writing my own VTK filter and helper classes and have been running
into some difficulty properly implementing the reference counting routines.
The problem stems from the fact that I have loops in my pipelines, and I
want to keep my class hierarchy free to include extra links.  E.g. an object
diagram might look like:

	Case 1: external1 -> A
      Case 2: external1 -> A <- external2
	Case 3: external1 -> A <-> B <- external2
	Case 4: external1 -> A <-> B <-> C <- external2

Where a "->" or a "<-" represents a one-way reference and a "<->" represents
a two-way reference (a two-object loop).

If external1's reference is removed from A, then the diagrams look like:

	Case 1: A
      Case 2: A <- external2
	Case 3: A <-> B <- external2
	Case 4: A <-> B <-> C <- external2

In case 1, there are no paths from external references to A, so it should be
deleted (and its internal reference count is 0).  In case 2, A has a
reference count of 1 and there is an external reference pointing directly to
it, so it isn't deleted.  For cases 3 and 4, there is an indirect path to an
external reference, so A is not deleted in either of these two cases.

Now, suppose that external1 was removed, then external3 pointed to a copy of
case 4, and then external2 was removed:

	Case 1: A
      Case 2: A
	Case 3: A <-> B
	Case 4: A <-> B <-> C
	Case 5: external3 -> A <-> B <-> C

In cases 1 and 2, A's reference count is 0, so it's deleted.  In case 3,
when external2 is removed, B's reference count is 1 (due to A).  It might be
smart enough to know that A is pointing to it, as some of the standard VTK
objects do.  In such a case, it might be smart enough to delete the A<->B
combination.  Things get more complicated in cases 4 and 5.  In both of
these cases, the external2 link being removed leaves C with only one direct
reference from a known loop-paired object.  However, in case 5 there is an
external reference pointing somewhere in the reference-connected structure
of C, but in case 4 there isn't.  Case 4 should have the whole thing
collapsed, but case 5 should not delete anything.

I've attempted to look at the guts of how VTK internally handles the
reference counting and I've run into sparse and sometimes stale comments.
Does anyone know if the existing VTK architecture is able to handle these
more complicated reference graphs?  Alternatively, does anyone know of any
books, etc. where I can learn more about memory management?

--Gerald Dalley
  dalleyg at ee.eng.ohio-state.edu
  dalleyg at dma.org