GC and finalizers [was: No destructor]

Michael Hudson mwh21 at cam.ac.uk
Sat Sep 2 14:30:07 CEST 2000

Paul Duffin <pduffin at hursley.ibm.com> writes:

> Rainer Deyke wrote:
> > 
> > "Paul Duffin" <pduffin at hursley.ibm.com> wrote in message
> > news:39AF7855.E5BA69A8 at hursley.ibm.com...
> > > So how are these "unbreakable" cycles supposed to be prevented, the only
> > > way that I can see is to remove finalizers from classes which may find
> > > themselves in a cycle. The trouble with this is that the finalizers are
> > > there for a purpose and it may not be possible to remove them.
> > >
> > > What can be done in this situation to prevent "unbreakable" cycles ?
> > 
> > All cycles should be treated as bugs.
> > 
> That seems a very limiting position to take. The optional GC in 2.0 will 
> collect cycles without finalizers so that is probably not the opinion of 
> the BDFL, otherwise the GC would probably raise errors.

Well, the point is that there are situations in which the gc has no
way of working out the order to finalise objects in (Is it really
undecidable?  Maybe), so if you want to be certain to avoid these then
you have two options:

  1) don't create cycles
  2) don't use finalizers

Neither of these is really practical, so I generally try to avoid both
as much as possible.


  Ya, ya, ya, except ... if I were built out of KSR chips, I'd
  be running at 25 or 50 MHz, and would be wrong about ALMOST
  EVERYTHING almost ALL THE TIME just due to being a computer!
                                              -- Tim Peters, 30 Apr 97

More information about the Python-list mailing list