Hi! [Copying guile-devel as some of the discussion hit there in July, and I'd like feedback]
So with regards to guile-gnome's GC problems[0,1], I have been doing some poking around today. What I think I have determined is that we cannot call scm_unprotect_object in any callback that GObject calls, because these callbacks can be called during GC sweep, normally in reaction to our smobs' free functions. Marius says[2] that this is not supported, so we need to change. We need to be able to react to these callbacks (for example, closure invalidation, qdata being removed, etc), but we can't change SCM values from in those callbacks. So like Marius does in guile-gtk[3], and like Gregory proposed in his patch[4], we should adapt our approach to something more compatible with mark/sweep: we should create a special SMOB that marks objects that we know about. Instead of calling scm_protect_object, we add our object to the set of objects that that SMOB tracks; likewise with unprotect. We should only be protecting SCM proxies for objects that are being kept alive from C via refcounts; that is, C objects whose refcount is more than 1[5]. GObject has a facility for this now, the very confusing "toggle refs"[6]. We can make the proxy->GObject reference a toggle reference, only protecting the SCM value if the refcount of the object is above 1. With regards to closures, I think that we should also mark them via this same mechanism. The closure proxy would then remove them from the protected set when it is invalidated by GLib, and GObject would invalidate the closures when the GObject goes away. This is what the Python bindings do. There are some details to work out, but it seems like a reasonable plan. So, thoughts appreciated, especially from Gregory :) I'll look at implementing this this weekend. [0] http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html [1] http://thread.gmane.org/gmane.lisp.guile.devel/5971/focus=5971 [2] http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4134 [3] line 198 and forward in http://cvs.savannah.gnu.org/viewcvs/guile-gtk/guile-gtk-1.2/guile-gtk.c?annotate=1.99 [4] http://lists.gnu.org/archive/html/guile-gtk-general/2006-07/msg00056.html [5] This ignores Marius' attempt at tracing internal references. That's ok because what guile-gtk currently does is just tracking kids of gtk_container, which the above solution treats just as well. [6] http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html Cheers, Wingo. -- http://wingolog.org/ _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
