From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: doco scm_remember_upto_1 Date: Thu, 12 Jun 2003 09:07:54 +1000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <877k7snrg5.fsf@zip.com.au> References: <87wugjhowm.fsf@zip.com.au> <87wugjqx1g.fsf@raven.i.defaultvalue.org> <87r86rqa6m.fsf@raven.i.defaultvalue.org> <87vfw1i1jq.fsf@zip.com.au> <87add5mh91.fsf@zip.com.au> <87isrpjx0a.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1055372789 24467 80.91.224.249 (11 Jun 2003 23:06:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 11 Jun 2003 23:06:29 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jun 12 01:06:28 2003 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 19QEfj-0006MV-00 for ; Thu, 12 Jun 2003 01:06:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QEhc-0004HT-RM for guile-devel@m.gmane.org; Wed, 11 Jun 2003 19:08:24 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19QEhO-00046l-V0 for guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:10 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19QEhJ-0003wq-3C for guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:05 -0400 Original-Received: from snoopy.pacific.net.au ([61.8.0.36]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19QEhG-0003kp-Sy for guile-devel@gnu.org; Wed, 11 Jun 2003 19:08:03 -0400 Original-Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) h5BN80Yd031697 for ; Thu, 12 Jun 2003 09:08:00 +1000 Original-Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5BN7xQg006684 for ; Thu, 12 Jun 2003 09:07:59 +1000 (EST) Original-Received: from localhost (ppp124.dyn228.pacific.net.au [203.143.228.124]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5BN7wYZ020262 for ; Thu, 12 Jun 2003 09:07:58 +1000 (EST) Original-Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19QEh8-0000iz-00; Thu, 12 Jun 2003 09:07:54 +1000 Original-To: guile-devel@gnu.org Mail-Copies-To: never User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2520 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2520 Marius Vollmer writes: > > But this is not the case, a GC will only run when all threads are > in a safe place and have been stopped. Right, yep. I reworded it in a more direct sense as follows, dropping the "it might be thought" business, which was only really me getting wrong ideas. In a multi-threaded program, the rule is the same. As far as a given thread is concerned, a garbage collect still only occurs within a memory allocation function, not at an arbitrary time. (Guile waits for all threads to reach a memory function, and holds them there while the collector runs.) > But when in doubt, be > conservative: include the call to scm_remember_upto_here_1 when > you are not sure that it is safe to leave it out. I think I'd rather see something unambiguous said about when a remember must be used, instead of talking about being unsure. I tried to reword a little to emphasise it's memory activity which provokes a gc. > A call to > scm_remember_1 will cost at most as much as a call to an empty > function. Or less, if the asm block approach is right, or if storing to a global "volatile" variable would similarly be right. :-) > Is that important? A note that says that the non-varargs functions > might be more efficient should suffice, no? I'm only thinking to encourage the best way. I suppose the cost is always going to be small compared to real work done, it's just a case of not wanting to go along an inferior path. In any event, I checked in the new section. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel