[vtk-developers] Disturbing garbage collection behavior.

[Wylie, Brian]

I feel a group hug coming on... :)


Brian Wylie - Org 9227
Sandia National Laboratories
MS 0822 - Building 880/A1-J
(505)844-2238 FAX(505)845-0833                       
     ____                  _    __
    / __ \____  _________ | |  / (_)__ _      __ 
   / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
  / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
 /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/

                                    Unleash the Beast
 

> -----Original Message-----
> From: vtk-developers-bounces at vtk.org 
> [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Brad King
> Sent: Thursday, March 03, 2005 7:04 AM
> To: Moreland, Kenneth
> Cc: vtk-developers at vtk.org
> Subject: Re: [vtk-developers] Disturbing garbage collection behavior.
> 
> 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
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
> 
>