[Openmcl-devel] async signals

Gábor Melis mega at hotpop.com
Mon Sep 19 01:27:27 PDT 2005

On Monday 19 September 2005 07:57, Gary Byers wrote:
> 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.

Maybe you're not talking about the behaviour I proposed in


But if you are, then the wording is misleading. We agree that deferring 
interrupts for cleanup forms or during unwinding is not a good thing in 
all situations. Hence the proposal allows interrupts and only handles 
asynchronous unwinds specially. That way, most of the interruptions 
(profiling, C-c, sigchld handling, ...) succeed, but those that try to 
unwind are aborted/retried-later/continued unsafely. Sorry, if that was 
clear already.

> 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.

I'm more and more convinced that who-can-interrupt-whom (aka interrupt 
priorities) is an almost orthogonal issue to asynchronous unwinds. Plus 
once async unwinds are dealt with, some of the interrupt priority 
problems are solved too.


More information about the Openmcl-devel mailing list