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: [PATCH] Marking weak alist vectors Date: Wed, 07 Dec 2005 01:55:29 +0200 Message-ID: <87vey13hn2.fsf@zagadka.de> References: <87y83z3vh5.fsf@laas.fr> <874q6m7l6d.fsf@zagadka.de> <87lkzyyyzw.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1133913553 22882 80.91.229.2 (6 Dec 2005 23:59:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2005 23:59:13 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 07 00:59:10 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EjmgN-0003B7-5B for guile-devel@m.gmane.org; Wed, 07 Dec 2005 00:57:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EjmgY-0000Kv-S1 for guile-devel@m.gmane.org; Tue, 06 Dec 2005 18:57:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ejmev-0007x7-Np for guile-devel@gnu.org; Tue, 06 Dec 2005 18:55:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ejmeu-0007wh-PZ for guile-devel@gnu.org; Tue, 06 Dec 2005 18:55:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ejmeu-0007we-Ha for guile-devel@gnu.org; Tue, 06 Dec 2005 18:55:44 -0500 Original-Received: from [213.243.153.35] (helo=smtp2.pp.htv.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ejmff-0006cD-2A for guile-devel@gnu.org; Tue, 06 Dec 2005 18:56:31 -0500 Original-Received: from zagadka.ping.de (cs181072157.pp.htv.fi [82.181.72.157]) by smtp2.pp.htv.fi (Postfix) with SMTP id 690E0296C08 for ; Wed, 7 Dec 2005 01:55:29 +0200 (EET) Original-Received: (qmail 6551 invoked by uid 1000); 6 Dec 2005 23:55:29 -0000 Original-To: guile-devel@gnu.org In-Reply-To: <87lkzyyyzw.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Wed, 09 Nov 2005 10:03:15 +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:5473 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > IOW, property values are to be "collected" _after_ the Scheme value to > which they are attached has been collected. The manual talks from the perspective of a Scheme program here. For a Scheme program, the important information is that some object is not collected _before_ some condition is true. Thus, the wording in the manual should be read as 'not before' instead of as 'strictly after'. Maybe we should change the manual accordingly. C code can observe the GC doing its thing (via the smob free functions). In order not to overconstrain the implementation of the GC (which is pretty constrained already anyway), we have the additional rule that there is no guarantee about the order in which objects are swept during the sweep phase. Why do you need this guarantee? (If you really need this feature, I will start talking you into using guardians to enforce some order on finalization.) > In any case, if a value P is attached as a property of some object O, > then O should be "collected" _before_ P. Why? Isn't it enough to say 'P is not collected before O is unreachable'? GC's usually don't make any guarantee about what happens with an object it has become unreachable. For example, once O and P become unreachable, it would be totally acceptable for a GC to collect P but to never get around to actually collect O. (The GC could be generational: O could be in the oldest generation and P in the youngest. The youngest generation might be collected every MiB of allocated memory, but the oldest generation might only be collected on weekends and during national holidays. :) --=20 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