From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: out-of-order GC Date: 01 Jan 2003 22:22:21 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <87bs30h8fm.fsf@zagadka.ping.de> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041456533 11200 80.91.224.249 (1 Jan 2003 21:28:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 1 Jan 2003 21:28:53 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18TqPz-0002uL-00 for ; Wed, 01 Jan 2003 22:28:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18TqQI-0003dG-06 for guile-user@m.gmane.org; Wed, 01 Jan 2003 16:29:10 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18TqPu-0003Ck-00 for guile-user@gnu.org; Wed, 01 Jan 2003 16:28:46 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18TqPE-00029I-00 for guile-user@gnu.org; Wed, 01 Jan 2003 16:28:06 -0500 Original-Received: from dialin.speedway42.dip71.dokom.de ([195.138.42.71] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10.13) id 18TqJo-0008EH-00 for guile-user@gnu.org; Wed, 01 Jan 2003 16:22:28 -0500 Original-Received: (qmail 16292 invoked by uid 1000); 1 Jan 2003 21:22:21 -0000 Original-To: redhog@redhog.org In-Reply-To: Original-Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: General Guile related discussions List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:1495 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1495 Egil Moeller writes: > > Fortunately, resource smobs can check, in their free functions, > > whether this has happened, by looking at the SCM_TYP16 of their > > reference to the display smob. If the display smob is still valid, > > this will be scm_tc16_xdisplay, and the relevant X resource should > > be freed as normal. If the display smob has been freed earlier in > > this sweep, GC will have set its SCM_TYP16 to scm_tc_free_cell; > > this indicates that XCloseDisplay has already been called, and so > > the relevant X resource no longer needs to be freed. */ > > Aha, so that's how it should be done. Hmm. I think it would be better not to rely on this detail of how the GC works. I don't think we want to guarantee that you can always tell whether a particular cell has been freed during this GC. For example, we might change the GC so that it gives heap segments back to the OS when all their cells are on a freelist. These cells are then `off limits' to the application. Or the GC might play tricks with the MMU and make free cells write-only... You could simply use scm_tc_free_cell anyway, being prepared to find a new solution when your hack stops working, or you could add a reference count to the C connection struct and point directly to it from the C transaction object. The connection could then stay around long enough. There are probably other solutions as well. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user