[Bug 111028] Dealing with reference cycles in GObject

["J. Ali Harlow" <ali avrc city ac uk>]

I have a problem with the win32 port of Gtk+ which is producing
lots of error messages and I suspect also at least partly
reponsible for the resource leak which is making my application
unusable. The problem itself is documented in bug 111028 which
I am now attempting to fix myself.

I'm running into difficulties because I don't really understand
how GObject is supposed to handle the case of cyclic references.
The situation is that under win32 GdkImages have an associated
GdkPixmap and vica-versa. The situation is further complicated
by the fact that gdk_drawable_get_image() called on a GdkPixmap
returns the associated GdkImage (rather than creating a new
GdkImage and copying the pixels across).

I can see a number of possible ways forward, but I'd appreciate
some input from those of you who actually understand GObject:

1. Add full reference counting so that if you create a new
   GdkImage you get back an object with a reference count of
   1 (for the reference held in the associated GdkPixmap).
   The associated GdkPixmap also has a reference count of 1
   (for the reference held in the GdkImage). There are no
   floating references. Clearly this will need a garbage
   collection scheme to look for GdkImages with a reference
   count of 1 and whose associated GdkPixmap also has a
   reference count of exactly 1. Great care is going to have
   to be taken to ensure that new images/pixmaps aren't
   picked up by the garbage collector before they are referenced
   for the first time.

2. Add a flag to both images and pixmaps that marks them as
   either being a "master" or a "slave". Master objects
   use g_object_ref/unref to count their reference to slave
   objects; slave objects do not. This works well for images
   where the associated pixmap is basically an implementation
   detail but more care would be needed for pixmaps for which 
   the user can gain a reference to the associated image. If
   the user did this and then unreferenced the pixmap causing
   it to be finalized the image would have no associated pixmap
   if we're not careful. I think this could be solved by making
   the slave->master references weak references and by trapping
   the fact that the master is about to be disposed and swapping
   the master/slave relationship in the weak pointer handler
   (would this work?).

3. Change gdk_drawable_get_image() to always return a copy of the
   image. This is much easier but would reduce efficiency.

Or something that I haven't even thought of...

Many thanks for your help,

-- 
Ali Harlow                              Email: ali avrc city ac uk
Research programmer                     Tel:   (020) 7040 4348
Applied Vision Research Centre          Intl: +44 20 7040 4348
City University                         Fax:   (020) 7040 5515
London                                  Intl: +44 20 7040 5515