[Python-Dev] Weak references: dereference notification

[Gustavo J. A. M. Carneiro]

Qui, 2005-11-10 às 08:15 +0100, "Martin v. Löwis" escreveu:
> Gustavo J. A. M. Carneiro wrote:
> >   OK, but what if it is a subclass of a builtin type, with instance
> > variables?  What if the PyObject is GC'ed but the ObjC object remains
> > alive, and later you get a new reference to it?  Do you create a new
> > PyObject wrapper for it?  What happened to the instance variables?
> 
> Normally, wrappers don't have state. But if you do have state, this
> is how it could work:
> 
> 1. Make two Python objects, PyState and PyWrapper (actually,
>     PyState doesn't need to be a Python object)
>     PyState holds the instance variables, and PyWrapper just
>     holds a pointer to a GObject.
> 2. When a Python reference to a GObject is created for the
>     first time, create both a PyState and a PyWrapper. Have
>     the GObject point to the PyState, and the PyWrapper to
>     the GObject. Have the PyState weakly reference the
>     PyWrapper.
> 3. When the refcount to the PyWrapper drops to zero, discard it.
> 4. When somebody asks for the data in the PyWrapper,
>     go to the GObject, then to the PyState, and return the
>     data from there.
> 5. When somebody wants a reference to a GObject which already
>     has a PyState, check the weak reference to find out
>     whether there is a PyWrapper already. If yes, return it;
>     if not, create a new one (and weakly reference it).
> 6. When the GObject is discarded, drop the PyState as well.
> 
> This has the following properties:
> 1. There are no cyclic references for wrapping GObjects.
> 2. Weakly-referencing wrappers is supported; if there
>     are no strong Python references to the wrapper,
>     the wrapper goes away, and, potentially, the GObject
>     as well.
> 3. The PyState object lives as long as the GObject.
> 4. Using "is" for GObjects/PyWrappers "works": there is
>     at most one PyWrapper per GObject at any time.
> 5. id() of a GObject may change over time, if the wrapper
>     becomes unreferenced and then recreated.

  This was my first approach, actually, in patch 4.1 in [1].  Only your
property 2 above drove me to try a different approach -- the weakrefs
may become invalid while the GObject may still be alive.  That's a bit
"surprising".  Of course, if I could override weakref.ref() for GObject
wrapper types, even that could be worked around... ;-)

  Thanks,

[1] http://bugzilla.gnome.org/show_bug.cgi?id=320428
-- 
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.