Re: SCM_DEFER_INTS versus error

From: Marius Vollmer <mvo@zagadka.de>
Cc: Mikael Djurfeldt <djurfeldt@nada.kth.se>
Subject: Re: SCM_DEFER_INTS versus error
Date: Thu, 18 Sep 2003 00:58:19 +0200	[thread overview]
Message-ID: <87ekyf9g50.fsf@zagadka.ping.de> (raw)
In-Reply-To: <87el0028c2.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 05 Aug 2003 11:37:17 +1000")

Kevin Ryde <user42@zip.com.au> 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