From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: SCM_DEFER_INTS versus error Date: Fri, 19 Sep 2003 13:34:34 -0700 (PDT) Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <200309192034.NAA04855@morrowfield.regexps.com> References: <87el0028c2.fsf@zip.com.au> <87ekyf9g50.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1064003451 15752 80.91.224.253 (19 Sep 2003 20:30:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2003 20:30:51 +0000 (UTC) Cc: djurfeldt@nada.kth.se, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 19 22:30:49 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 1A0Rtx-0001OS-00 for ; Fri, 19 Sep 2003 22:30:49 +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 1A0Rsu-0002n1-6s for guile-devel@m.gmane.org; Fri, 19 Sep 2003 16:29:44 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 1A0Rsm-0002kX-41 for guile-devel@gnu.org; Fri, 19 Sep 2003 16:29:36 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 1A0Rsj-0002kA-83 for guile-devel@gnu.org; Fri, 19 Sep 2003 16:29:33 -0400 Original-Received: from [65.234.195.45] (helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A0Rsh-0002j4-Cn for guile-devel@gnu.org; Fri, 19 Sep 2003 16:29:32 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id NAA04855; Fri, 19 Sep 2003 13:34:34 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: mvo@zagadka.de In-reply-to: <87ekyf9g50.fsf@zagadka.ping.de> (message from Marius Vollmer on Thu, 18 Sep 2003 00:58:19 +0200) 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:2810 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2810 > From: Marius Vollmer Have things _really_ diverged so far that the following no longer applies? Just a word of caution: > 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. > SCM_DEFER_INTS would, well, defer the execution of signal handlers > until the next ALLOW_INTS. Originally, it had nothing to do with > threads. It did more than that, at least in the late days of when I was maintainer. For example, some C functions were safe to invoke within the dynamic context of DEFER/ALLOW, others were not. It was a handy hack, that shook out many bugs, to: a) add a declaration in the body of each function that indicated when it could be safely run b) write an analyzer that roughly parsed the C code, did flow analysis, and labeled each call as "known ok", "known bogus", or "too complex to analyze". (Have you dropped the SCM_INTS_{ENABLED,DISABLED,INDIFFERENT} decls?!?) > I don't think we should keep the current meaning of DEFER/ALLOW. > Instead, we should make them noops and deprecate their usage. We > should be able to make them noops right now. Mikael, do you agree? 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 have a different model for signal delivery now: Scheme signal > handlers are always deferred and are run by SCM_TICK, when it is safe > to do so. > So there no longer is the danger of code being interrupted in a > massive way (of course, C signal handlers still run asynchronously, > but they are careful not to mess things up). Isn't there still a danger of bogusly calling a function that can, for example, invoke GC at a point in the code at which the heap is in a bogus state? DEFER/ALLOW is useful, at least, for finding that statically or at least noticing it dynamically. In short, there's an extensible bunch of invariants that characterize the heap and flow-control state. Modules that add new tyeps and functions can add new invariants. The dynamic segments between DEFER/ALLOW are where (and only where) those invariants can be violated. One way to look at it that might be helpful: you have a kind of virtual machine with the scheme heap as its store. That VM has an infinitely extensible set of macro-instructions as new C code is added. C itself is a kind of "micro-code" and the DEFER/ALLOW pairs mark the boundaries between macro-isntructions. Say, do you still have REDEFER/REALLOW? -t _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel