[Python-Dev] finalization again (original) (raw)

M.-A. Lemburg mal@lemburg.com
Wed, 08 Mar 2000 09:36:57 +0100

[Guido] The question remains, what to do with trash cycles? I find having a separate cleanup protocol cumbersome. I think that the "finalizer only called once by magic" rule is reasonable. I believe that the ordering problems will be much less than in Java, because we use topsort whenever we can.

Note that the cleanup protocol is intended to break cycles before calling the garbage collector. After those cycles are broken, ordering is not a problem anymore and because cleanup can do its task on a per-object basis all magic is left in the hands of the programmer.

The cleanup protocol as I use it is designed to be called in situations where the system knows that all references into a cycle are about to be dropped (I typically use small cyclish object systems in my application, e.g. ones that create and reference namespaces which include a reference to the hosting object itself). In my application that is done by using mxProxies at places where I know these cyclic object subsystems are being referenced. In Python the same could be done whenever the interpreter knows that a certain object is about to be deleted, e.g. during shutdown (important for embedding Python in other applications such as Apache) or some other major subsystem finalization, e.g. unload of a module or killing of a thread (yes, I know these are nonos, but they could be useful, esp. the thread kill operation in multi-threaded servers).

After cleanup has done its thing, the finalizer can either choose to leave all remaining cycles in memory (and leak) or apply its own magic to complete the task. In any case, del should be called when the refcount reaches 0. (I find it somewhat strange that people are argueing to keep external resources alive even though there is a chance of freeing them.)

-- Marc-Andre Lemburg

Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/