[Openmcl-devel] async signals

[Gary Byers]

On Sun, 18 Sep 2005, David L. Rager wrote:

> As an end user of the openmcl threads and unwind-protect features, you
> all might be interested in knowing that when using unwind-protect, I
> have wanted both cases (for using both within the same function even -
> the code is messy, but the result is potentially beautiful):
> 1. The cleanup form is interruptible
> 2. The cleanup form is protected from interrupts
>
> Since I want both cases, I think it's best to leave it interruptible,
> and I, the user, will continue to wrap a "without-interrupts" around
> whatever cleanup forms I don't want interrupted.
>
> The following scenario remains as currently undefined/illdefined in my
> mind (openmcl may address this concern):
>
> (defun foo ()
>  (unwind-protect
>    (something-fun)
>    (without-interrupts
>      (something-I-want-done))))
>
> 1. Enter the cleanup part of foo's unwind-protect
> 2. Get interrupted and told to die right before whatever
> without-interrupts expands to is entered
> 3. something-I-want-done will never run now, because it was able to
> receive the interrupt
>
> While unlikely, from a safety perspective, it might be nice to have an
> "unwind-protect-disable-interrupts-during-cleanup" construct. I'll be
> curious to hear if OpenMCL addresses this issue, or if they decided it
> was so unlikely it wasn't worth spending valuable time on.
>

What I'm sort of stuck on is the question of "which is more important:
running the cleanup form, or responding to the request to die ?"  I
don't think that there's a universally applicable answer to that (and
the half-formed notion of this being somehow similar to the motivation
for interrupt priorities is one approach to thinking about this that
hasn't led me anywhere concrete but that I haven't completely dismissed,
either.)

It may be a little complicated to implement, but it's certainly
possible to define things so that asynchronous interrupts are disabled
from (for instance) the point where a THROW begins to the point where
it ends (or more generally for the start and end points of any type of
unwinding, including falling off the end of an UNWIND-PROTECT
protected form.)  That would seem to avoid the timing screws that
could prevent a cleanup form from executing, but it also sort of
changes the policy from "abort requests are more important than
cleanup actions" to the opposite, and neither of those policies sounds
universally right.

If this change were made (not right now, but "soon", e.g., for the
next version), that -might- be a step in the right direction; it
sounds a little better if the problem moves from "we don't have
100% certainty that cleanup code will run" to "it's sometimes hard
to get threads to respond to interrupts, especially when they're
executing a long series of unwind-protect cleanups."  The latter
-sounds- more benign, but it may be hard to know for sure until
we get there.  (There's also this abstract issue that code in
the cleanup forms runs in the same dynamic environment that was
in effect for the protected forms; if we changed that to be "...
except for the fact that interrupts are disabled", that -might-
be a practical issue as well as an abstract one.)

If we had ways of saying "this code can be interrupted, but whoever
does so had better have a very good reason", and ways determining how
good a reason is, that might or might not lead to better solutions.

> Threaded LISP is great,
> David
>