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