From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: Need for scm_remember_upto_here_* in guile-2.0 Date: Tue, 22 Sep 2015 12:24:07 -0400 Message-ID: <878u7yfmmw.fsf@netris.org> References: <20150912132725.5a5e539c@bother.homenet> <87d1xamrmz.fsf@gnu.org> <87fv26bhlw.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1442939159 23197 80.91.229.3 (22 Sep 2015 16:25:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2015 16:25:59 +0000 (UTC) Cc: guile-user@gnu.org, David Kastrup To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 22 18:25:55 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 1ZeQO9-00009u-AJ for guile-user@m.gmane.org; Tue, 22 Sep 2015 18:25:53 +0200 Original-Received: from localhost ([::1]:41393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeQO8-0007vu-KU for guile-user@m.gmane.org; Tue, 22 Sep 2015 12:25:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeQO1-0007ve-HL for guile-user@gnu.org; Tue, 22 Sep 2015 12:25:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeQO0-0001sb-41 for guile-user@gnu.org; Tue, 22 Sep 2015 12:25:45 -0400 Original-Received: from world.peace.net ([50.252.239.5]:49144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeQNt-0001oQ-SJ; Tue, 22 Sep 2015 12:25:37 -0400 Original-Received: from [10.1.10.32] (helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1ZeQNc-0000QA-LV; Tue, 22 Sep 2015 12:25:20 -0400 In-Reply-To: <87fv26bhlw.fsf@fencepost.gnu.org> (David Kastrup's message of "Tue, 22 Sep 2015 17:26:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.252.239.5 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:12026 Archived-At: David Kastrup writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> In practice scm_remember_upto_here_* is useless with libgc, since libgc >> also tracks pointers in registers. > > Sounds like a big non-sequitur. scm_remember_upto_here_* is for keeping > SCM values active (including in registers). Any conversion of an SCM > value to some other data depending on it will not protect the SCM value > as such and may lead to collection/finalization of the SCM cell (calling > guardians, removing from weak hashtables and so on). I think David is right. Consider the following case: a SMOB contains a pointer to a block allocated by 'malloc' and freed by the SMOB freeing procedure. Some C code starts with a SCM value for that SMOB, uses it to obtain a pointer to the malloc'd block, and then discards the SCM value and proceeds to do a long-running job on the malloc'd block. If there are no other references to the SCM value, Boehm GC can free the SMOB and call its finalizer, which frees the malloc'd block. The long-running job in C continues to access the freed block. Am I missing something? Mark