From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: Need for scm_remember_upto_here_* in guile-2.0 Date: Wed, 23 Sep 2015 17:45:55 +0100 Message-ID: <20150923174555.1cc0e6ce@bother.homenet> References: <20150912132725.5a5e539c@bother.homenet> <87d1xamrmz.fsf@gnu.org> <87fv26bhlw.fsf@fencepost.gnu.org> <878u7yfmmw.fsf@netris.org> <87h9mmjgxi.fsf@gnu.org> <20150923003509.69409f72@laptop.homenet> <20150923004838.7215fe7d@laptop.homenet> <87r3lpa95o.fsf@fencepost.gnu.org> <20150923094146.3f66b926@laptop.homenet> <87eghpa52d.fsf@fencepost.gnu.org> <20150923104049.26603786@laptop.homenet> <8761319v8c.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443027234 9362 80.91.229.3 (23 Sep 2015 16:53:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 16:53:54 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Sep 23 18:53:44 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZenIZ-0008OD-Q0 for guile-user@m.gmane.org; Wed, 23 Sep 2015 18:53:39 +0200 Original-Received: from localhost ([::1]:49278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZenIZ-0007xx-BP for guile-user@m.gmane.org; Wed, 23 Sep 2015 12:53:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZenIQ-0007xP-So for guile-user@gnu.org; Wed, 23 Sep 2015 12:53:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZenIM-0002kl-Uf for guile-user@gnu.org; Wed, 23 Sep 2015 12:53:30 -0400 Original-Received: from smtpout3.wanadoo.co.uk ([80.12.242.59]:23896 helo=smtpout.wanadoo.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZenIM-0002ik-Nm for guile-user@gnu.org; Wed, 23 Sep 2015 12:53:26 -0400 Original-Received: from bother.homenet ([95.146.110.153]) by mwinf5d37 with ME id Lglt1r00V3JdQaf03gltYY; Wed, 23 Sep 2015 18:45:54 +0200 X-ME-Helo: bother.homenet X-ME-Date: Wed, 23 Sep 2015 18:45:54 +0200 X-ME-IP: 95.146.110.153 Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with ESMTP id 9B1718598B for ; Wed, 23 Sep 2015 17:45:55 +0100 (BST) In-Reply-To: <8761319v8c.fsf@fencepost.gnu.org> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.12.242.59 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12036 Archived-At: On Wed, 23 Sep 2015 14:27:15 +0200 David Kastrup wrote: [snip] > No, I cannot give you hard and fast rules for woods. I still have my > preferences, and there are reasons for them. And there may be > multiple reasons that are mostly independent. I wasn't asking for rules. I was trying to extract your meaning in an intelligible form. I think what you are approximately saying is that libgc as a conservative garbage collector is not particularly good in all cases (although I suspect that that is more likely to result in leaks rather than unwanted finalisation), that notwithstanding this it is better at detecting whether an allocated smob cell is still in use rather than some other things (of which the allocated data struct kept by the smob cell and any arrays are an example), and that therefore you think you are generally better off in letting libgc handle the smob cell with diligent use of remembering by the programmer, and handle other things yourself, including the smob's data struct and its members, by allocating them with malloc() and by explicit deallocation in the smob's finalisers (which in turn means you need a mark function for any SCM members of a malloc()'ed smob struct, which doesn't apparently work correctly). My modest requirements mean that I do not need to follow your advice, but even so I am grateful for your views. Chris