On Wed, 2005-08-10 at 10:39 +0200, Tomasz Wegrzanowski wrote:
> This is cross-posted to ruby-gnome2-devel-en lists sourceforge net
> and gtk-devel-list gnome org, because the problem was initially found
> with Ruby/GNOME2, but it seems extremely difficult to fix without serious
> changes to Gtk itself.
>
> The post is probably unnecessarily long, but I want to
> avoid any possible misunderstanding of the problem.
- For the idea:
"That is, when the last reference from the Gtk to the object is
dropped, we weaken the Gtk object"
See my mail "Introducing toggle references"
http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html
This facility is present in GLib-2.8
- In terms of adding support for mark-and-sweep collection in GLib,
I basically don't think it will happen, though it has been
proposed before, the first time just about 5 years ago:
http://mail.gnome.org/archives/gtk-devel-list/1998-September/msg00033.html
Why not?
A) Only a very limited set of language garbage collectors are sufficiently
customizable that this is useful (Python, Ruby, maybe Guile), but
it's a pretty intrusive change.
B) Once you've found circular garbage, how do you free it? If you
are lucky, one piece in the circular garbage is a GtkWidget and
you can call gtk_widget_destroy() on it and hope that breaks the
cycle.
C) In practice, such problems come up quite rarely, largely because
we've designed around them:
- There is an explicit gtk_widget_destroy()
- Signal handlers are removed when a widget is destroyed
- We avoid having reference count cycles in GTK+ objects themselves
(parents reference children, children do not reference parents,
and so forth)
Also see:
http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00137.html
For discussion of a technique for avoiding another type of common
refcount cycle.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part