Portable keyboard signal handling
Friends, I have a Haskell library that is currently GHC-only. However, I'm working on making it more portable, with the short-term goal of running on Hugs and the hope of being Haskell' compliant when the time comes. One problem I've run into is that I need a way to portably handle Ctrl-C. On Posix systems, this can be done in a pretty straightforward manner using System.Posix.Signals. However, for win32, I've been relying on the GHC.ConsoleHandler module, which is obviously GHC-specific. Because the module is short, I've attached the complete code text to the end of this message. So, my question is, what should my strategy be? I could snarf the entire contents of GHC.ConsoleHandler into my project (yuck!). I could try to get the ConsoleHandler module out of the GHC walled garden. I could try to get the 'withControlCHandler' function into a future release of the standard libs . Or... What do you think? Have I missed some other option? Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG module System.Console.Shell.ConsoleHandler ( withControlCHandler ) where import qualified Control.Exception as Ex #ifndef mingw32_HOST_OS import qualified System.Posix.Signals as PS withControlCHandler :: IO () -> IO a -> IO a withControlCHandler hdl m = Ex.bracket (PS.installHandler PS.keyboardSignal (PS.Catch hdl) Nothing) (\oldh -> PS.installHandler PS.keyboardSignal oldh Nothing) (\_ -> m) #else import qualified GHC.ConsoleHandler as CH handleCtrlC :: IO () -> CH.Handler handleCtrlC hdl = CH.Catch $ \ev -> case ev of CH.ControlC -> hdl _ -> return () withControlCHandler :: IO () -> IO a -> IO a withControlCHandler hdl m = Ex.bracket (CH.installHandler (handleCtrlC hdl)) (\oldh -> CH.installHandler oldh) (\_ -> m) #endif
Hi,
One problem I've run into is that I need a way to portably handle Ctrl-C.
I do too, but that module has absolutely no documentation on the web (http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-ConsoleHandle...), so rather unsurprisingly I missed that entirely! I also need to raise Ctrl-C on a process I have started from Haskell, so if that could be also done in a portable way then I'd be happy :) Thanks Neil
On Thursday 31 August 2006 16:01, Neil Mitchell wrote:
Hi,
One problem I've run into is that I need a way to portably handle Ctrl-C.
I do too, but that module has absolutely no documentation on the web (http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-ConsoleHand ler.html), so rather unsurprisingly I missed that entirely!
Indeed. I had to browse the source after finding that the Haddock docs are essentially useless. I do have to say, one nice side effect of using darcs is that one can simply point one's browser at the source repository to peruse the code. I've bookmarked http://cvs.haskell.org/darcs :-)
I also need to raise Ctrl-C on a process I have started from Haskell, so if that could be also done in a portable way then I'd be happy :)
This is also an issue. I only need to handle the events, but I can certainly see the utility of generating them as well.
Thanks
Neil
-- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG
| Indeed. I had to browse the source after finding that the Haddock docs are | essentially useless. I do have to say, one nice side effect of using darcs | is that one can simply point one's browser at the source repository to peruse | the code. I've bookmarked http://cvs.haskell.org/darcs :-) Good idea. Could you help us improve the documentation by sending darcs patches with Haddock docs in them? Not necessarily comprehensive: at least recording the bits you discovered, and wished had been in the docs in the first place. Thanks! Simon
Simon Peyton-Jones wrote:
| Indeed. I had to browse the source after finding that the Haddock docs are | essentially useless. I do have to say, one nice side effect of using darcs | is that one can simply point one's browser at the source repository to peruse | the code. I've bookmarked http://cvs.haskell.org/darcs :-)
Good idea. Could you help us improve the documentation by sending darcs patches with Haddock docs in them? Not necessarily comprehensive: at least recording the bits you discovered, and wished had been in the docs in the first place.
The real issue here is that we're generating Haddock docs for the libraries as they appear to a Unix user, and hence leaving out all the Windows-specific stuff. The main thing we need to do is include the Win32 package in the docs, and there may be a few other minor things. Cheers, Simon
On Friday 01 September 2006 03:55, Simon Peyton-Jones wrote:
| Indeed. I had to browse the source after finding that the Haddock docs are | essentially useless. I do have to say, one nice side effect of using darcs | is that one can simply point one's browser at the source repository to peruse | the code. I've bookmarked http://cvs.haskell.org/darcs :-)
Good idea. Could you help us improve the documentation by sending darcs patches with Haddock docs in them? Not necessarily comprehensive: at least recording the bits you discovered, and wished had been in the docs in the first place.
Well, here's the odd thing; there ought to be meaningful haddock docs already. By that, I mean that there are data declarations and type signatures and such already in the file that haddock should be picking up on. However, the whole file is protected by a big ifdef: module GHC.ConsoleHandler #if !defined(mingw32_HOST_OS) && !defined(__HADDOCK__) where import Prelude -- necessary to get dependencies right #else /* whole file */ ( Handler(..) , installHandler , ConsoleEvent(..) , flushConsole ) where ..... rest of file .... It looks like the definitions in the file _should_ be visible to haddock, but for some reason they aren't. So, this looks like a build system problem of some sort to me. I don't know how the docs are built, so I'm not sure how one would go about fixing this.
Thanks!
Simon
Do you have any ideas about the original question? It looks like RTS trickery is necessary to get this right in general. Looking at this file in a little more detail, I see calls to 'rts_installHandler', which is surely why this file is in the GHC.* namespace. Perhaps 'withControlCHandler' or something like it should go into the libraries somewhere? I'm not sure this is a function that can be provided without RTS assistance. It also seems to be about the maximum intersection of the capabilities of Posix signals and of the Win32 console events system. -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG
Robert Dockins wrote:
On Friday 01 September 2006 03:55, Simon Peyton-Jones wrote:
| Indeed. I had to browse the source after finding that the Haddock docs are | essentially useless. I do have to say, one nice side effect of using darcs | is that one can simply point one's browser at the source repository to peruse | the code. I've bookmarked http://cvs.haskell.org/darcs :-)
Good idea. Could you help us improve the documentation by sending darcs patches with Haddock docs in them? Not necessarily comprehensive: at least recording the bits you discovered, and wished had been in the docs in the first place.
Well, here's the odd thing; there ought to be meaningful haddock docs already. By that, I mean that there are data declarations and type signatures and such already in the file that haddock should be picking up on. However, the whole file is protected by a big ifdef:
module GHC.ConsoleHandler #if !defined(mingw32_HOST_OS) && !defined(__HADDOCK__) where import Prelude -- necessary to get dependencies right #else /* whole file */ ( Handler(..) , installHandler , ConsoleEvent(..) , flushConsole ) where
..... rest of file ....
It looks like the definitions in the file _should_ be visible to haddock, but for some reason they aren't.
The !defined(__HADDOCK__) part was added by me recently, so you have to look in the snapshot docs to find the results: http://www.haskell.org/ghc/dist/current/docs/libraries/base/GHC-ConsoleHandl... GHC.ConsoleHandler is now included in the documentation, and will be in 6.6.
Do you have any ideas about the original question? It looks like RTS trickery is necessary to get this right in general. Looking at this file in a little more detail, I see calls to 'rts_installHandler', which is surely why this file is in the GHC.* namespace.
Perhaps 'withControlCHandler' or something like it should go into the libraries somewhere? I'm not sure this is a function that can be provided without RTS assistance. It also seems to be about the maximum intersection of the capabilities of Posix signals and of the Win32 console events system.
Right, that would be useful. However, see this bug: http://hackage.haskell.org/trac/ghc/ticket/637 Ctrl-C doesn't work right on Windows with -threaded, at the moment. (we hope to get to this one for 6.6.1). Cheers, Simon
Hello Robert, Thursday, August 31, 2006, 11:49:45 PM, you wrote:
So, my question is, what should my strategy be? I could snarf the entire contents of GHC.ConsoleHandler into my project (yuck!). I could try to get the ConsoleHandler module out of the GHC walled garden. I could try to get the 'withControlCHandler' function into a future release of the standard libs . Or...
i'm sure that this module relies on some RTS magick beacuse one of my bugreports (http://hackage.haskell.org/trac/ghc/ticket/637) was that CTRL-C handling don't works with -threaded RTS -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (5)
-
Bulat Ziganshin -
Neil Mitchell -
Robert Dockins -
Simon Marlow -
Simon Peyton-Jones