[Openmcl-devel] async signals

[Gábor Melis]

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

  http://www.caddr.com/macho/archives/sbcl-devel/2005-9/6018.html

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.

Gábor