...

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. 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 finally found the cause of this. The ghc RTS has a global variable `interrupted', which is set by its interrupt handler, and tested by various other parts of the scheduler.

Guess what - my C routines also have a global variable called `interrupted', and my own ^C interrupt handler was also setting this variable. D'oh. If I change the name of my global variable, then everything works as it ought to.

I know it's a pain for you, but can I file this as a bug report in ghc? Stealing simple and obvious global identifiers from the user's namespace is rather dangerous, and even more so when it is undocumented.

These global "common" variables are a pain in the neck. There are 44 of these in GHC's RTS - we should really at the least initialise them so that you'll get a conflict if you define a global with the same name in your own code. Thanks for the report. Cheers, Simon