From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: scheme closures: crash during garbage collection Date: Sat, 08 Jul 2006 18:06:37 +0300 Message-ID: <87u05s2l1e.fsf@zagadka.de> References: <64e2f6fe0606081528m4e5f9979yff9b8294ecedf6d2@mail.gmail.com> <87odx2ds0o.fsf@ossau.uklinux.net> <87mzclmjq8.fsf@zagadka.de> <87odwyt33x.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1152371211 19108 80.91.229.2 (8 Jul 2006 15:06:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 8 Jul 2006 15:06:51 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jul 08 17:06:49 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FzEOM-0003Md-09 for guile-devel@m.gmane.org; Sat, 08 Jul 2006 17:06:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzEOL-0000At-J1 for guile-devel@m.gmane.org; Sat, 08 Jul 2006 11:06:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FzEOJ-0000Ah-8T for guile-devel@gnu.org; Sat, 08 Jul 2006 11:06:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FzEOG-00009y-VC for guile-devel@gnu.org; Sat, 08 Jul 2006 11:06:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzEOG-00009v-Pp for guile-devel@gnu.org; Sat, 08 Jul 2006 11:06:40 -0400 Original-Received: from [213.243.153.35] (helo=smtp2.pp.htv.fi) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FzEOv-00033y-D9 for guile-devel@gnu.org; Sat, 08 Jul 2006 11:07:21 -0400 Original-Received: from zagadka.ping.de (cs181072157.pp.htv.fi [82.181.72.157]) by smtp2.pp.htv.fi (Postfix) with SMTP id 8D97F296BEE for ; Sat, 8 Jul 2006 18:06:38 +0300 (EEST) Original-Received: (qmail 4993 invoked by uid 1000); 8 Jul 2006 18:06:37 +0300 Original-To: Neil Jerram In-Reply-To: <87odwyt33x.fsf@ossau.uklinux.net> (Neil Jerram's message of "Mon, 12 Jun 2006 23:34:42 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5997 Archived-At: Neil Jerram writes: >> Guile wants you to integrate your objects with its mark/sweep >> approach, by providing appropriate smob marking functions, for >> example. > > If I've understood correctly, this isn't possible in Gregory's > scenario. > > (See > http://lists.gnu.org/archive/html/guile-gtk-general/2006-06/msg00013.html > if you didn't see the whole description on guile-gtk-general already.) I think this (and also the problem of reference loops that easily form over widgets and signal handlers) has been successfully solved in the guile-gtk bindings of yore: http://www.gnu.org/software/guile-gtk/ Here is the comment describing the wrapping strategy for GObjects: /* GtkObjects. GtkObjects are wrapped with a smob. The smob of a GtkObject is called its proxy. The proxy and its GtkObject are strongly connected; that is, the GtkObject will stay around as long as the proxy is referenced from Scheme, and the proxy will not be collected as long as the GtkObject is used from outside of Scheme. The lifetime of GtkObjects is controlled by a reference count, while Scheme objects are managed by a tracing garbage collector (mark/sweep). These two techniques are made to cooperate like this: the pointer from the proxy to the GtkObject is reflected in the reference count of the GtkObject. All proxies are kept in a list and those that point to GtkObjects with a reference count greater than the number of `internal' references are marked during the marking phase of the tracing collector. An internal reference is one that goes from a GtkObject with a proxy to another GtkObject with a proxy. We can only find a subset of the true internal references (because Gtk does not yet cooperate), but this should be good enough. By using this combination of tracing and reference counting it is possible to break the cycle that is formed by the proxy pointing to the GtkObject and the GtkObject pointing back. It is straightforward to extend this to other kind of cycles that might occur. For example, when connecting a Scheme procedure as a signal handler, the procedure is very likely to have the GtkObject that it is connected to in its environment. This cycle can be broken by including the procedure in the set of Scheme objects that get marked when we are tracing GtkObjects with a reference count greater than the number of internal references. Therefore, each proxy contains a list of `protects' that are marked when the proxy itself is marked. In addition to this, there is also a global list of `protects' that is used for Scheme objects that are somewhere in Gtk land but not clearly associated with a particular GtkObject (like timeout callbacks). */ -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel