Re: Proposal: new signal-handling API

On Sat, 2008-07-19 at 08:29 -0700, Bryan O'Sullivan wrote:

On Fri, Jul 18, 2008 at 5:55 AM, Simon Marlow 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