From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: SCM_DEFER_INTS versus error Date: Mon, 22 Sep 2003 20:01:12 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87smmod7o7.fsf@zagadka.ping.de> References: <87el0028c2.fsf@zip.com.au> <87ekyf9g50.fsf@zagadka.ping.de> <200309192034.NAA04855@morrowfield.regexps.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1064253905 15800 80.91.224.253 (22 Sep 2003 18:05:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2003 18:05:05 +0000 (UTC) Cc: djurfeldt@nada.kth.se, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Sep 22 20:04:56 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A1V3Q-0006t1-00 for ; Mon, 22 Sep 2003 20:04:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A1V07-000667-Iw for guile-devel@m.gmane.org; Mon, 22 Sep 2003 14:01:31 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 1A1Uzv-000650-Hp for guile-devel@gnu.org; Mon, 22 Sep 2003 14:01:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 1A1Uzu-00064V-3I for guile-devel@gnu.org; Mon, 22 Sep 2003 14:01:18 -0400 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A1Uzs-00063c-Qh for guile-devel@gnu.org; Mon, 22 Sep 2003 14:01:17 -0400 Original-Received: from zagadka.ping.de (unknown [192.168.2.2]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with SMTP id DE3E1BA8D for ; Mon, 22 Sep 2003 20:01:12 +0200 (CEST) Original-Received: (qmail 17430 invoked by uid 1000); 22 Sep 2003 18:01:12 -0000 Original-To: Tom Lord In-Reply-To: <200309192034.NAA04855@morrowfield.regexps.com> (Tom Lord's message of "Fri, 19 Sep 2003 13:34:34 -0700 (PDT)") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2816 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2816 Tom Lord writes: > > From: Marius Vollmer > > Have things _really_ diverged so far that the following no longer > applies? Yes, I would say so. > > The whole DEFER/ALLOW business is anachronistic (in my view at least) > > and should go away. Originally, it was used to mark sections of code > > that could not tolerate being interrupted, at a time when POSIX > > signals could run Scheme code right from the signal handler and that > > Scheme code could invoke continuations or throw to a catch. > > More specifically, they marked segments of code during which the heap > and flow-control could be in an inconsistent state as far as the usual > macros, gc, etc. were concerned. That's an "extended" notion of > "inconsitent state" -- it included data structures and system state > that most of scheme didn't care about at all but that had to be > correlated with scheme heap state and flow of control. Yes, your are right of course. Not only interrupts could mess things up, but they were the only asynchronous source of lossage. The only other source would be a programming error, right? > (Have you dropped the SCM_INTS_{ENABLED,DISABLED,INDIFFERENT} decls?!?) I didn't even know they were there, at some time! So, yes, they are gone, too. > Traditionally, as an example, between DEFER/ALLOW, the > pointer-to-malloced-data in an object such as string was not required > to be valid. Consequently, GC had to be excluded between > DEFER/ALLOW. We now do this with careful coding only. Still having the DEFER/ALLOW markups in the code is helpful for statically checking this, as you say. Hmm... -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel