Re: How to determine if a GObject is "contained"?



Hans, i haven't read all you wrote, but from what i read i think you
can solve the problem by using toggle_ref. It was a new API that was
added to GObject on the lastest release, exactly to solve binding
issues.

There was a long dicussion about this on java-gnome-hackers, and now
Java-Gnome uses that toggle_ref API. It also does some other tricks to
solve other memory management "problems".

Cheers,
J.V.


2005/11/16, Hans Oesterholt-Dijkema <hdnews gawab com>:
>
>
> Why would a garbage collector be in any way interested in a resource
>  that was not explicitly allocated by the calling application code ?
>  It's not. My goal is to never have to use "g_object_unref" from scheme.
>  The GC can do that for me. However, I also do not want gobjects to
>  be prematurely destroyed.
>
>  So what I do, as can be seen from the code sample 3, is, a GObject
>  proxy scheme object takes ownership of all GtkObjects and GObjects
>  that it gets to see.
>
>  You can see this overtaking of ownership in code sample 3. The
>  decision procedure for taking over ownership for GtkObjects is
>  obvious. When I floats, mzgtk2 takes ownership. When a GtkObject
>  is added to a container, the reference count will increase. When
>  the scheme object associated with it goes out of scope in scheme,
>  the GC will clean up the proxy object, and while cleaning up, the
>  reference count to the GtkObject is decreased. However, because
>  the GtkObject had previously been added to a container, the container
>  will be the last one (seen from the Gtk world) to have a reference
>  to the GtkObject.
>
>  With GObjects it is more difficult. They are not floating. It is
>  impossible to detect, weather it has been created by some Gxyz_new()
>  call, or as part of an other structure. When creater by some Gxyz_new()
>  call, the code in code sample 3 does it's job right. By not increasing
>  the reference count of GObjects with ref_count 1, it takes ownership
>  of the GObject. However, this doesn't hold for GObjects that
>  are already owned by an other GObject, as is the case for a GtkImage
>  with a GdkPixbuf created from file.
>
>  Now, what happens if I do nothing while accessing the GdkPixbuf of
>  a GtkImage (e.g., to set an icon with gtk_window_set_icon())?
>
>  Because the ref. count of the GdkPixbuf = 1, mzgtk2 will take owenership
>  of it, by not increasing the reference count. Now the GdkPixbuf is owned
>  by the GtkImage and mzgtk2. And there it goes wrong. I hand the GtkPixbuf
>  over to the gtk_window (using gtk_window_set_icon()). The reference
>  count to the GtkPixbuf is increased to 2 by that call. Next, the GdkPixbuf
>  goes out of scope in scheme. The reference count drops to 1. Next, the
>  GtkImage (which was created within some scope and is no longer necessary)
>  goes out of scope, and the reference count drops to 0. What the..., now
>  the GdkPixbuf is cleaned from memory, while still in use by the GtkWindow.
>
>  Ok, I need some decision procedure to determine if I get a GObject that
>  is already owned or if I get a *new* GObject.
>
>  Still following? More to follow beneath the code sample.
>
>
>
>
>  ===========================================
>   if (GTK_IS_OBJECT(g)) {
>     if (GTK_OBJECT_FLOATING(g)) {
>        g_object_ref(g);
>        gtk_object_sink(g);
>     }
>     else {
>        g_object_ref(g);
>     }
>   }
>   else if (gobject_ref_count(g)>1) {
>     g_object_ref(g);
>   }
>  ===========================================
>
>  May I ask why you aren't referencing objects that
>  have a ref_count of "1" and why you are not adding
>  a reference to floating GtkObjects ?
>  So, that's to take ownership of these Objects, so that the
>  Garbage Collector can do it's normal cleaning job.
>
>
>  I obviously dont know enough about your project to solve
>  your problem, but I hope this was helpfull anyway.
>  Best whishes and thanks,
>
>  Hans Oesterholt-Dijkema.
>
>
>
>  Cheers,
>                          -Tristan
>
>
>
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]