Proposal: new signal-handling API

[John Goerzen]

Duncan Coutts wrote:
> On Fri, 2008-07-18 at 13:55 +0100, Simon Marlow wrote:
>> I've just submitted a proposal for a new signal-handling API, the ticket is 
>> here:
>>
>>    http://hackage.haskell.org/trac/ghc/ticket/2451
>>
>> Deadline: 1 Aug (2 weeks).
> 
> I'm happy with it. It's relatively simple now (earlier iterations had
> more states).
> 
> The main question is if it's too simple. Can people who know about and
> use signals take a look and see if it covers everything? I'm cc'ing a
> couple more people who know about and use signals.

Thanks for that.  I'm on a train to OSCon right now, so my apologies for 
typos or late replies (my net connection is not terribly stable so I 
can't see the whole thing.)

Overall I think the goal of being able to add signal handlers without 
disturbing what's there is a good one, and being able to add multiple 
handlers like that is a good plan too.

I do have a few things I'd like to make sure are addressed, though. 
Maybe they are (again, a bit hard to read from my train)...

1) Instead of deprecating the low-level API, I would prefer to have it 
still available -- ideally with the new API implemented in terms of it. 
  I can see cases where I really want to make the handler be what I say, 
not anything else.  For instance, say some library was catching SIGABRT 
for its own purposes, but in a certain section of code, I really want 
SIGABRT to be handled in a certain way.  Using the old API, I could save 
off the old handler, install a new handler that does what I want, and 
restore the old one later (assuming I didn't dump core).

This is important because, for many signals, the "normal" way to handle 
it might be to do something and then crash.  For instance, if you get 
sigabrt, maybe you print out some state, then crash.  So if something 
installed a signal handler that crashes, you may be stuck if you don't 
want to crash.

It could also be important if you really don't want other signals 
handlers doing anything.  Say you've got a library that installs a 
handler for SIGINT that flushes out some buffer and prepares things for 
the progam to terminate nicely.  But in a certain part of your code, you 
don't want to handle SIGINT at all (or you absolutely want it to be 
handled only by saying putStrLn "Don't press Ctrl-C now, you dolt!"). 
Since adding a signal handler could be opaque, this could be quite 
difficult.  With the proposed system, you never know if some module has 
installed a signal handler, which could be an issue in itself.

2) It would be nice to at least have the option of atomic handlers in 
Haskell.  I realize this is not a regression over 6.8.2.  Failing that, 
it would be nice to have it documented whether forkIO or forkOS is used.

3) I hope you will not be deprecating System.Posix.Signals.Exts

4) Some signals such as SIGPWR are missing in both 6.8.2 and the new system

Thanks for your work on this.  These are probably not popular cases.  On 
the other hand, I have tended to run into limitations in System.Posix in 
the past in areas that weren't anticipated to be popular cases ;-)

-- John

> 
> In particular, one simplification we made from an earlier design is that
> it's not possible to go back to the default OS signal action without
> explicitly removing all handlers. Previously there was a set of handlers
> and an independent signal state, ignore, default or handled. Now the
> state follows the set of handlers so when the set is empty then we get
> the default signal action. There is no ignore state as such but one can
> override the default handler by adding a handler that does nothing.
> 
> So each handler is relatively independent. You can't interfere with
> another handler unless you have access to its HandlerId. That would seem
> to be a good thing but I might be missing some use case.
> 
> Duncan
> 
>