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 +--------------------------------------+