From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: the new gc asserts in master Date: Thu, 28 Aug 2008 01:33:47 -0300 Message-ID: References: <873akq3nsy.fsf@gnu.org> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1219898136 29418 80.91.229.12 (28 Aug 2008 04:35:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2008 04:35:36 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Aug 28 06:36:30 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KYZFA-0003rI-9Q for guile-devel@m.gmane.org; Thu, 28 Aug 2008 06:36:24 +0200 Original-Received: from localhost ([127.0.0.1]:39670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYZEB-0007v6-TV for guile-devel@m.gmane.org; Thu, 28 Aug 2008 00:35:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYZE6-0007ti-2w for guile-devel@gnu.org; Thu, 28 Aug 2008 00:35:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYZE5-0007t6-Cg for guile-devel@gnu.org; Thu, 28 Aug 2008 00:35:17 -0400 Original-Received: from [199.232.76.173] (port=49353 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYZE5-0007t1-8I for guile-devel@gnu.org; Thu, 28 Aug 2008 00:35:17 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:56799 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KYZE4-0008Nb-OM for guile-devel@gnu.org; Thu, 28 Aug 2008 00:35:17 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KYZE2-0005za-GL for guile-devel@gnu.org; Thu, 28 Aug 2008 04:35:14 +0000 Original-Received: from 201.80.3.52 ([201.80.3.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Aug 2008 04:35:14 +0000 Original-Received: from hanwen by 201.80.3.52 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Aug 2008 04:35:14 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 201.80.3.52 User-Agent: Thunderbird 2.0.0.16 (X11/20080723) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:7525 Archived-At: Andy Wingo escreveu: > Hi again! > > On Wed 27 Aug 2008 12:00, Andy Wingo writes: > >> On Wed 27 Aug 2008 07:00, Han-Wen Nienhuys writes: >> >>>>>> http://thread.gmane.org/gmane.lisp.guile.user/6372 >>> I think reference counting is the correct solution for this, as far as >>> I understand the problem from the quoted message. >> I don't think so; the use case is that (1) we don't want to prevent the >> C object from being freed, so we don't want to hold a reference on the C >> object; but (2) we do want to know when it is freed, so we can release >> our cache; but (3) we want to get the scheme object back if the object >> has not in fact been swept. As far as I understand, you are splitting the decision whether an object is live (reachable) between C and SCM - it's reachable when there is an SCM reference, but it is also reachable when there is no SCM reference anymore, but it is still reachable by looking at a C table and returning the SCM reference inside the C struct. You can never get a consistent model if you try to split it up like that. Either the memory management is entirely in SCM (using (weak) hash tables in SCM and GC which decides whether an object is reachable) or the memory management is entirely in C (eg. using ref counting). If you try to mix both, you'll get a frankenstein with cloudy semantics and edgy corner cases. > I don't think this is exactly right. I was discussing this on IRC with > Ludovic and he made me come out with a better characterization of the > problem. > > Consider a C object, `C'. We wrap it in scheme with a SCM object, `S'. S > has a reference on C, using reference counting. C has some kind of API > to associate S with it: set_ptr() and get_ptr(). Cool. > > So what happens if we get C back from a callback at some time in the > future? Well we call get_ptr(C) and return that if it's non-null. > Otherwise we make a new smob and call set_ptr (C, S) and then return S. > > So what happens if the scheme object becomes collectable? Well S has a > free function which will unref the C object and set_ptr (C, NULL). This > is also OK. > > But what if it goes like this: > > S becomes collectable in theory > > mark phase: S is indeed marked as collectable > > C is returned from a callback: get_ptr() return S > > at some later time the card containing S is swept; S's free function > is run, and S is marked as a free cell Here you are dividing the responsibity of liveness between SCM and C. SCM decides the object is dead, but you hold on to it in in C, and then insert the dead reference back into SCM, leading to crappage. I think it is wrong to equate (destructor has run) with (object is reachable). One of the important points of GC (RAII will say it's a detractor) vs. C++ smart pointer is that going out of scope and running the destructor to go with that can happen at different points in time. Between these points, the objects are in a sort of limbo: you can't do return them back to the 'live' part of the program, but the destructror hasn't run yet. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen