Proposal: new signal-handling API

[Duncan Coutts]

On Sat, 2008-07-19 at 08:29 -0700, Bryan O'Sullivan wrote:
> On Fri, Jul 18, 2008 at 5:55 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> > I've just submitted a proposal for a new signal-handling API, the ticket is
> > here:
> 
> Thanks, Simon. I generally like the proposal, particularly the modular
> aspect of signal handling.

> I think that if Johan's request for a lower-level API were followed,
> that would also satisfy John's desire for more explicit control.

I do understand the desire for that. The downside of course is that a
lower level api has to be used very carefully to avoid breaking the
promises provided by the higher level api.

So we should discuss what lower level api is required exactly and
document how people can use it without breaking the higher level api.

I'd also prefer to have some use cases for the lower level api (rather
than just having it there for its own sake) since I suspect that most of
them can be solved in better and more portable ways than using signals
directly (eg using exceptions).

In particular the case of "I need to do this cleanup before the program
terminates" is much more general than Posix and signals. For example a
library installing a handler for SIGINT is the wrong thing to do (and
not just because it's not very modular) but because the very decision
about whether SIGINT is going to kill the process or not is not for the
library to decide. What it needs is to be thrown an exception when the
process does decide that it's going to terminate.

> I notice that there is no binding for sigwaitinfo/sigtimedwait. Is
> this deliberate?

There is and it's not changed by Simon's proposal:

awaitSignal :: Maybe SignalSet -> IO
()
Source
        awaitSignal iset suspends execution until an interrupt is
        received. If iset is Just s, awaitSignal calls sigsuspend,
        installing s as the new signal mask before suspending execution;
        otherwise, it calls pause. awaitSignal returns on receipt of a
        signal. If you have installed any signal handlers with
        handleSignal, for example, it may be wise to call yield directly
        after awaitSignal to ensure that the signal handler runs as
        promptly as possible.

Incidentally this can be re-implemented using the new api in such a way
that it does not block the whole OS thread as sigwaitinfo/sigtimedwait
does. Actually the way it works now doesn't interact very well at all
because it swallows the signal so the other handlers do not run.

Duncan