From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Marking weak alist vectors Date: Wed, 07 Dec 2005 11:33:41 +0100 Organization: LAAS-CNRS Message-ID: <8764q1tcvu.fsf@laas.fr> References: <87y83z3vh5.fsf@laas.fr> <874q6m7l6d.fsf@zagadka.de> <87lkzyyyzw.fsf@laas.fr> <87vey13hn2.fsf@zagadka.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1133964786 26570 80.91.229.2 (7 Dec 2005 14:13:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Dec 2005 14:13:06 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 07 15:13:04 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ejzyl-0006Sp-7y for guile-devel@m.gmane.org; Wed, 07 Dec 2005 15:09:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ejzuk-0001c4-4L for guile-devel@m.gmane.org; Wed, 07 Dec 2005 09:04:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EjwgH-0002Ni-1q for guile-devel@gnu.org; Wed, 07 Dec 2005 05:37:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EjwfE-0002FP-Dr for guile-devel@gnu.org; Wed, 07 Dec 2005 05:36:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ejwdw-00027n-3E for guile-devel@gnu.org; Wed, 07 Dec 2005 05:35:25 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Ejwek-0006R9-Ev for guile-devel@gnu.org; Wed, 07 Dec 2005 05:36:14 -0500 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id jB7AZ5ol022547; Wed, 7 Dec 2005 11:35:05 +0100 (CET) Original-To: Marius Vollmer X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 17 Frimaire an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Marius Vollmer , guile-devel@gnu.org In-Reply-To: <87vey13hn2.fsf@zagadka.de> (Marius Vollmer's message of "Wed, 07 Dec 2005 01:55:29 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:5483 Archived-At: Marius Vollmer writes: > 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. Relaxing such constraints may work for Scheme objects that are entirely under Guile's control, but it certainly isn't acceptable when SMOBs come into play: SMOBs _will_ from time to time be victims of this, resulting in double-frees and the likes. SMOBs shouldn't ever have the impression that a value attached to a weak key is freed _before_ that weak key. From the SMOB programmer viewpoint that is really an error, no matter if it's "before but during the same phase" or not. > Why do you need this guarantee? For a concrete example, you may want to look at `test-weaks.c' which I posted when this discussion started, i.e. a long time ago. ;-) For a more general example where this is an issue: http://lists.nongnu.org/archive/html/g-wrap-dev/2005-09/msg00006.html (see at the bottom). > (If you really need this feature, I will start talking you into using > guardians to enforce some order on finalization.) I hadn't look into this so far, and indeed, that looks interesting! That's a nice reflexive approach to GC. I don't think it solves my very problem though. >> 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'? If user-definable objects (SMOBs) didn't exist, that would be perfectly fine. But the mere existence of SMOBs prevents such optimizations. Why would we like to retain such sloppy semantics which are problematic to the C (SMOB) programmer? Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel