Avoiding scm_protect_object

[Andy Wingo <wingo@pobox.com>]

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
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel