Proposal: new signal-handling API

[Simon Marlow]

John Goerzen wrote:

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

So one reason I wanted to deprecate the old API is that with signals run in 
separate threads it didn't really make sene.  For example, asking for a 
signal to be ignored isn't useful on its own: there might be signal 
handlers for that signal already running, or just started and about to run. 
  Blocking signals suffers from the same problem.  (I know I left the 
blocking primitives around in the new API, I should really deprecate them 
though).

Synchronising with signal handlers should be done using ordinary thread 
synchronisation.  Have one big signal lock if you like, or one per signal, 
or one per handler - it's up to you.

It's true that you can't synchronise with other people's signal handlers 
this way.  But I think that's a feature, or at least not a bug.  Even using 
SIG_IGN or sigprocmask() you couldn't stop a handler that had already been 
started anyway.

To do what you describe with SIGINT, you would:

  - say to the default ^C handler "don't deliver any ^C exceptions until I
    tell you otherwise" (GHC 6.9+ has a default ^C handler, and there will
    be a way to communicate/synchronise with it or disable it).

  - install another handler temporarily to do putStrLn "don't press ^C...".

Random libraries would not be adding ^C handlers to do cleanup.  Libraries 
that need cleanup should be providing a function

   withMyLib :: IO a -> IO a

that does a "finally"-style action to perform the cleanup.

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

The idea of atomic signal handlers in the context of GHC scares me :-) 
Either the handler would have to avoid touching any kind of shared resource 
(e.g. a Handle) to avoid deadlock, or we'd have to block signals whenever 
another thread was holding the resource (not really practical).  The list 
of things you could do in a signal handler would be pretty small - most I/O 
would be out.

Also signal handlers are not atomic even in POSIX when there are multiple 
threads, right?  They're only atomic with respect to the current OS thread, 
which is not a concept we have in GHC.

Yes I'm talking about GHC specifics here, but we want to design an API that 
makes sense in multiple settings, and GHC is a setting in which atomic 
handlers wouldn't work, I think.

> 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

Someone should add those to System.Posix.Signals.Exts, yes.