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: Thu, 18 Sep 2003 00:58:19 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87ekyf9g50.fsf@zagadka.ping.de> References: <87el0028c2.fsf@zip.com.au> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1063995286 31705 80.91.224.253 (19 Sep 2003 18:14:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2003 18:14:46 +0000 (UTC) Cc: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 19 20:14:44 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 1A0PmF-0000qB-00 for ; Fri, 19 Sep 2003 20:14:44 +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 1A0PkR-0006gs-8P for guile-devel@m.gmane.org; Fri, 19 Sep 2003 14:12:51 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.22) id 1A0Pk0-0006dM-2i for guile-devel@gnu.org; Fri, 19 Sep 2003 14:12:24 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 1A0Pjx-0006cc-Bl for guile-devel@gnu.org; Fri, 19 Sep 2003 14:12:22 -0400 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A0Pjw-0006cR-U7 for guile-devel@gnu.org; Fri, 19 Sep 2003 14:12:21 -0400 Original-Received: from dialin.speedway42.dip208.dokom.de ([195.138.42.208] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1A0Plj-0000ad-00 for guile-devel@gnu.org; Fri, 19 Sep 2003 20:14:11 +0200 Original-Received: (qmail 27750 invoked by uid 1000); 17 Sep 2003 22:58:19 -0000 Original-To: guile-devel@gnu.org In-Reply-To: <87el0028c2.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 05 Aug 2003 11:37:17 +1000") 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:2809 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2809 Kevin Ryde writes: > I noticed in the little program below, the thread seems to get hung > after an error in the mainline has done an SCM_DEFER_INTS in strptime > then escaped with an error, apparently not doing an SCM_ALLOW_INTS. > > Is there a theory on what should happen with this? Is an error meant > to re-allow ints or should code be careful to do an ALLOW after any > DEFER? The latter no doubt makes sense irrespective of what an error > throw does. 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. SCM_DEFER_INTS would, well, defer the execution of signal handlers until the next ALLOW_INTS. Originally, it had nothing to do with threads. 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). With concurrent threads, we need to protect global data structures, but I would say that the existing DEFER/ALLOW markup is not the right tool for this. Right now (if I'm still uptodate), only one thread can execute 'in Guile', and thus we need no more explicit protection than for the old coop threads. Pragmatically, I don't think we can rely on DEFER/ALLOW to always come in perfectly balanced pairs and I don't think it is worthwhile to make sure that they do. The way DEFER/ALLOW are defined now (as locking/unlocking a mutex) is subtly different from what they did previously (setting/clearing a flag in a non-nested way). 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? > Incidentally, I don't think I understand why current-time has a > SCM_DEFER_INTS. A simple call to time() ought to be safe shouldn't > it? Yes. Traditionally, all calls to functions outside of libguile were wrapped in DEFER/ALLOW since we didn't want external functions to be interrputed by Scheme signal handlers. It was not to ensure proper behavior with preemptive threads. -- 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