[Python-Dev] Making weakref callbacks safe in cyclic gc
nas-python at python.ca
Mon Nov 17 12:54:57 EST 2003
On Mon, Nov 17, 2003 at 11:06:57AM -0500, Tim Peters wrote:
> it doesn't really matter which objects are reachable from the
> objects whose deaths trigger callbacks, what really matters is
> which objects are reachable from the callbacks themselves.
Right, it's all about what that nasty user code can do. :-)
> So what's reachable from a callback? If the callback is not *itself* part
> of the garbage getting collected, then it acts like an external root, and so
> nothing reachable from the callback is part of the garbage getting collected
> either. gc has no worries then.
> If the callback itself is part of the garbage getting collected, then the
> weakref holding the callback must also be part of the garbage getting
> collected (else the weakref holding the callback would act as an external
> root, preventing the callback from being part of the garbage being collected
> My thought then was that a simpler scheme could simply call tp_clear on the
> trash weakrefs first. Calling tp_clear on a weakref just throws away the
> associated callbacks (if any) unexecuted, and if they don't get run then we
> have no reason to care what's reachable from them anymore.
This I don't get. Don't people want the callbacks to be called?
I don't see how a weakref callback is different than a __del__
method. While the object is not always reachable from the callback
it could be (e.g. the callback could be a method). The fact that
callbacks are one shot doesn't seem to help either since the
callback can create a new callback.
More information about the Python-Dev