Algorithm for finalizing cycles (Re: [Python-Dev] Garbage collecting closures)

Greg Ewing greg@cosc.canterbury.ac.nz
Tue, 15 Apr 2003 16:51:23 +1200 (NZST)


> They're not trying very hard, then -- and, admittedly, most don't.
> For example, every time the library grabs a resource that needs
> finalization, it can plant a weakref to it in a singleton private
> module object with a __del__ method...

If you have to go through such convolutions to make __del__ methods
reliable, perhaps some other mechanism should be provided in the first
place.

What you're describing sounds a lot like a scheme used in a Smalltalk
system that I encountered once. Objects didn't have finalizing methods
themselves; instead, an object could register another object as an
"executor" to carry out its "last will and testament". This was done
*after* the object in question had been deallocated, and after all
other GC activity had finished, so there was no risk of resurrecting
anything or getting the GC into a knot.

Using weakrefs, it might be possible to implement something like
this in pure Python, for use as an alternative to __del__ methods.

> How?  I believe this is beyond realistic automated analysis for Python
> source.

I wasn't suggesting that it be automated, I was suggesting that it be
done explicitly.

Suppose, e.g. there were a special attribute __dontclear__ which can
be given a list of names of attributes that the GC shouldn't
clear. The author of a __del__ method would then have to make sure
that everything it needs is mentioned in that list, or risk having it
disappear.

> Even if we relied on programmers declaring their beliefs explicitly,
> Python still has to be paranoid enough to avoid crashing if the
> stated beliefs aren't really true.

I can't see how a crash could result -- the worst that might happen is
a __del__ method throws an exception because some attribute that it
relies on has been cleared. That's then a programming error in that
class -- the attribute should have been listed in __dontclear__.

> You probably need also to detect that the finalizer can't resurrect
> the object either, else clearing references that aren't needed
> specifically for finalization would leave the resurrected object in
> a damaged state.

Or just refrain from writing __del__ methods that are silly enough to
resurrect their objects. Or if resurrection really is necessary, put
all their vital attributes in __dontclear__.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+