GC and finalizers [was: No destructor]
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