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, 10 Jun 2006 12:40:47 +0300 Message-ID: <87mzclmjq8.fsf@zagadka.de> References: <64e2f6fe0606081528m4e5f9979yff9b8294ecedf6d2@mail.gmail.com> <87odx2ds0o.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 1149932460 4308 80.91.229.2 (10 Jun 2006 09:41:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 10 Jun 2006 09:41:00 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jun 10 11:40:58 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 1Fozxh-0003yu-1c for guile-devel@m.gmane.org; Sat, 10 Jun 2006 11:40:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fozxg-0001YX-J8 for guile-devel@m.gmane.org; Sat, 10 Jun 2006 05:40:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fozxd-0001YS-8k for guile-devel@gnu.org; Sat, 10 Jun 2006 05:40:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fozxa-0001Y5-Le for guile-devel@gnu.org; Sat, 10 Jun 2006 05:40:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fozxa-0001Y2-H6 for guile-devel@gnu.org; Sat, 10 Jun 2006 05:40:50 -0400 Original-Received: from [213.243.153.35] (helo=smtp2.pp.htv.fi) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fp05p-0000Fm-CJ for guile-devel@gnu.org; Sat, 10 Jun 2006 05:49: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 E941A296BCA for ; Sat, 10 Jun 2006 12:40:48 +0300 (EEST) Original-Received: (qmail 15437 invoked by uid 1000); 10 Jun 2006 12:40:48 +0300 Original-To: guile-devel@gnu.org In-Reply-To: (Han-Wen Nienhuys's message of "Fri, 9 Jun 2006 21:54:58 +0000 (UTC)") 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:5973 Archived-At: hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) writes: > In article <87odx2ds0o.fsf@ossau.uklinux.net>, > Neil Jerram wrote: > >>[...] >>It seems to me, though, that the same kind of situation, leading to >>wanting to call scm_gc_unprotect_object during GC, is likely to arise >>in any sufficiently complex application, and hence that we should >>support this within Guile itself. >>[...] >>Can people more familiar with the GC code comment on whether this fix >>is feasible? > > No, MV thinks it's a bad idea, and I agree with him. > > See > > http://thread.gmane.org/gmane.lisp.guile.devel/4117/focus=4160 Yep, and let me elaborate a bit: The pair scm_gc_protect_object / scm_gc_unprotect_object can be seen as being Guile's way to implement reference counting for its objects, maybe analogous to g_object_ref and g_object_unref for glib's GObjects. This is true, of course: you can use it to implement reference counting. However, it is not a good idea, as Guile offers a better alternative with its mostly-precise mark/sweep garbage collector. Using the protec/unprotect functions for references that change with a high frequency is quite expensive: Guile objects don't contain a reference count field, and protecting/unprotecting them is implemented by putting them in a global list and removing them again. Also, the 'reference counts' only need to be correct when the GC actually happens, and keeping them correct all the time is wasteful in that sense. Guile wants you to integrate your objects with its mark/sweep approach, by providing appropriate smob marking functions, for example. The function scm_gc_protect_object is intended for long living, global objects that are referenced from global C variables. If the global variable changes often and points to different objects, it might be a good idea to use scm_gc_register_root instead. -- 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