RE: (not) catching ^C in ghc-built application

I have a program, written in a mixture of Haskell and C, in which the C part is supposed to handle a ^C interrupt, accomplished through the usual signal() call. It works as expected when the Haskell part is compiled by nhc98. But when it is compiled by ghc, for some reason the ghc RTS appears to trap the interrupt itself, and halts the program with the message prog: interrupted instead of allowing the newly installed C signal handler to run.
I have looked through the ghc user manual for some means to turn off or divert the RTS signal-handling, but I couldn't find anything relevant. The nearest thing is Exception.block, which excludes an asynchronous exception from happening whilst the `block' is in operation, but that doesn't seem to stop a ^C from interrupting the program, so I guess that isn't its real purpose.
So, what should I use instead?
It's probably quite naughty of us to install a SIGINT handler without checking whether there was already one installed. The relevant code is in ghc/rts/Signals.c around line 359. If you send me a patch I'll incorporate it. For a quick workaround, if you install your own handler *after* calling startupHaskell(), you should be able to override GHC's. Cheers, Simon

"Simon Marlow"
It's probably quite naughty of us to install a SIGINT handler without checking whether there was already one installed. The relevant code is in ghc/rts/Signals.c around line 359. If you send me a patch I'll incorporate it.
Hmmm, ghc/rts/Signals.c only has 358 lines. :-) Maybe this is a clue as to why ghc has such dodgy line numbers in its error reports... No, hold on, `cvs update', ah that's better.
For a quick workaround, if you install your own handler *after* calling startupHaskell(), you should be able to override GHC's.
The thing is, that's what I'm already doing. At least, Haskell is in charge of the execution, and does quite a lot of things before calling out to an I/O action written in C, which then sets the handler. My best guess is that the use of signal() is incompatible with the POSIX sigaction() used by the RTS. Regards, Malcolm
participants (2)
-
Malcolm Wallace
-
Simon Marlow