RE: (not) catching ^C in ghc-built application
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.
That's possible I guess. Could you try using sigaction() instead? Cheers, Simon
My best guess is that the use of signal() is incompatible with the POSIX sigaction() used by the RTS.
That's possible I guess. Could you try using sigaction() instead?
No change in behaviour. Is it possible that ghc's scheduler might be re-installing signal handlers throughout the computation whenever it has control? For instance, if threads are allocated fixed processor time via the VTALRM signal, maybe when the alarm timer is restored? I had a quick look at ghc/rtc/Itimer.c, but this hypothesis doesn't look very likely. Regards, Malcolm
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. Regards, Malcolm
Neither of you should be using a global variable at all! Do something like this: struct _myglobals { . . . bool interrupted; . . . } myglobals; and then replace "interrupted" with "myglobals.interrupted". C has enough problems without using unqualified globals! On Tuesday 13 August 2002 07:36, Malcolm Wallace wrote:
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.
Regards, Malcolm _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- Seth Kurtzberg MIS 480-661-1849 Pager 888-605-9296 or 6059296@skytel.com Cell 480-620-1099
On 2002-08-13T07:34:54-0700, Seth Kurtzberg wrote:
Neither of you should be using a global variable at all! Do something like this:
struct _myglobals { . . . bool interrupted; . . . } myglobals;
and then replace "interrupted" with "myglobals.interrupted".
C has enough problems without using unqualified globals!
But if they *both* use the name "myglobals"... -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig "Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network." -- Tim Berners-Lee
But if they *both* use the name "myglobals"...
Then you find yourself a tool for renaming symbols in .o files and fix it. Should anyone feel the need for such a tool, grab 'Knit' (a component definition/ linking language for C), http://www.flux.utah.edu/flux/knit/software.html build it and grab knit/bin/rename_dot_o_files Your namespace contamination problems will be a thing of the past. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
participants (5)
-
Alastair Reid -
Ken Shan -
Malcolm Wallace -
Seth Kurtzberg -
Simon Marlow