RetroSearch Browse

Mon Nov 17 12:54:57 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040284.html

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.

Okay.

> 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
> too).
> 
> 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.

  Neil

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040284.html below:

[Python-Dev] Making weakref callbacks safe in cyclic gc