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: Need for scm_remember_upto_here_* in guile-2.0 Date: Sat, 12 Sep 2015 13:27:25 +0100 Message-ID: <20150912132725.5a5e539c@bother.homenet> 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 1442060861 26337 80.91.229.3 (12 Sep 2015 12:27:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2015 12:27:41 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Sep 12 14:27:33 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 1Zajtw-0001an-76 for guile-user@m.gmane.org; Sat, 12 Sep 2015 14:27:28 +0200 Original-Received: from localhost ([::1]:60639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zajtv-0001EO-A0 for guile-user@m.gmane.org; Sat, 12 Sep 2015 08:27:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zajtl-0001EF-1T for guile-user@gnu.org; Sat, 12 Sep 2015 08:27:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zajth-00072S-Ra for guile-user@gnu.org; Sat, 12 Sep 2015 08:27:16 -0400 Original-Received: from smtpout3.wanadoo.co.uk ([80.12.242.59]:40676 helo=smtpout.wanadoo.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zajth-000721-Kj for guile-user@gnu.org; Sat, 12 Sep 2015 08:27:13 -0400 Original-Received: from bother.homenet ([95.146.110.153]) by mwinf5d39 with ME id GCTB1r0043JdQaf03CTBTS; Sat, 12 Sep 2015 14:27:11 +0200 X-ME-Helo: bother.homenet X-ME-Date: Sat, 12 Sep 2015 14:27:11 +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 B9E5885AEA for ; Sat, 12 Sep 2015 13:27:25 +0100 (BST) 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:12013 Archived-At: Hi, The guile manual suggests (section 5.5.5) that if a smob's internals are referenced in a function after the last time that the SCM variable representing the smob is accessed in the function, scm_remember_upto_here_* should be used. Otherwise the suggestion is made that the optimizer may treat the smob as expended after the last access to its variable is made in the function, with the result that the collector may reclaim its memory, including any internals (in the case of the example in section 5.5.5, the smob's 'image' struct). scm_remember_upto_here_1() does this by the simple expedient of taking the SCM object as an argument and doing nothing, so the garbage collector still thinks the smob is in use until then. (This is fine as far as it goes although could perhaps be tripped up by link-time-optimization). However I am finding difficulty in understanding why that should be the case, because in that example all the smob's internals are allocated using scm_gc_malloc()/GC_MALLOC or scm_gc_malloc_pointerless()/ GC_MALLOC_ATOMIC. The garbage collector should therefore be fully aware of those internals and be able to mark them for survival if still in use, without any help from the programmer. Is the point here that the example code contains an unnecessary (and ill-advised) free function for the smob, which calls scm_gc_free() on its internals? If so, is the point that the scm_remember_upto_here_* functions are in practice only needed for smobs which provide their own free function? If so, that would further imply (in relation to the 'image' example) that finding a live managed pointer allocated by scm_gc_malloc() in the smob's data field (as passed when calling scm_new_smob()) does not save the smob from collection by the garbage collector (and so its free function being invoked by guile). Is that really the case? Regards, Chris