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, 14 Dec 2005 01:45:58 +0200 Message-ID: <87pso0tvbd.fsf@zagadka.de> References: <87y83z3vh5.fsf@laas.fr> <874q6m7l6d.fsf@zagadka.de> <87lkzyyyzw.fsf@laas.fr> <87vey13hn2.fsf@zagadka.de> <8764q1tcvu.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 1134518162 30725 80.91.229.2 (13 Dec 2005 23:56:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2005 23:56:02 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 14 00:56:01 2005 Return-path: Original-Received: from [199.232.75.2] (helo=lists.gnu.org) by ciao.gmane.org with esmtp (Exim 4.43) id 1EmJy4-0002sN-Br for guile-devel@m.gmane.org; Wed, 14 Dec 2005 00:54:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmJyd-00074J-0D for guile-devel@m.gmane.org; Tue, 13 Dec 2005 18:54:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EmJur-0004M7-Tg for guile-devel@gnu.org; Tue, 13 Dec 2005 18:50:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EmJuq-0004Ko-6q for guile-devel@gnu.org; Tue, 13 Dec 2005 18:50:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EmJup-0004Kd-U1 for guile-devel@gnu.org; Tue, 13 Dec 2005 18:50:39 -0500 Original-Received: from [213.243.153.35] (helo=smtp2.pp.htv.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EmJwo-0006g7-4O for guile-devel@gnu.org; Tue, 13 Dec 2005 18:52:42 -0500 Original-Received: from zagadka.ping.de (cs181072157.pp.htv.fi [82.181.72.157]) by smtp2.pp.htv.fi (Postfix) with SMTP id 5A9AE296BDB for ; Wed, 14 Dec 2005 01:50:02 +0200 (EET) Original-Received: (qmail 19597 invoked by uid 1000); 14 Dec 2005 01:46:00 +0200 Original-To: guile-devel@gnu.org In-Reply-To: <8764q1tcvu.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Wed, 07 Dec 2005 11:33:41 +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 X-Broken-Reverse-DNS: no host name found for IP address 199.232.75.2 Xref: news.gmane.org gmane.lisp.guile.devel:5507 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > 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 com= e > into play: SMOBs _will_ from time to time be victims of this, resulting > in double-frees and the likes. Yes, SMOBs could profit from a guarantee about the order of finalization, but I don't think that guarantee can be implemented cheaply enough. (Or can it?) So, my current point of view is that smobs have to suffer in order to make live easier for the GC. > SMOBs shouldn't ever have the impression that a value attached to a wea= k > key is freed _before_ that weak key. This would not only apply to weak keys etc, but to all kinds of references, right? I.e., all SCM values belonging to a smob would be guaranteed to be valid when the free function for that smob is called. Thus, we are not only talking about your patch for weak hash tables, but about big changes to the GC in general, right? >> 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. ;-) Heh, that is not an example, that is a test case. :-) > 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). (I only read the article you linked to directly, not the thread.) So you have a C API that requires a certain order for freeing objects and that order needs to be honored by the smobs that wrap the objects, right? My immediate reaction is to suggest to fix this by layering something on top of the C API, such as the reference counting that you mention in your article. (Refcounting is acceptable since cycles must be prevented anyway.) I agree that it would be nice to have Guile help with that, if only by providing proven example code. >> (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. Yeah, you might be right... > Why would we like to retain such sloppy semantics which are problematic > to the C (SMOB) programmer? Because we would need to change the GC significantly... that's the only reason I can think of. But note that the thing we are talking about now is very different from what you started out with: now we are not talking about in which run of the GC a value belonging to a weak key is collected (i.e., the key in run n, the value in run n+1), but in what order objects are finalized within a single run of the GC (if I am not confused now). --=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