I'm brand new to Haskell and in messing around with a few samples I've got a problem where I can't stop the program. I'm using Windows 7 and using runhaskell from ght. Ctrl-c doesn't work so I have to resort to the task manager which is a bit of a pain.
Instead of doing that how can I create a separate control thread that would wait until I typed q and then quit my Haskell application.
The application I've got the problem with is of the format:
main = do
h <- connectTo server (PortNumber (fromInteger port))
hSetBuffering h NoBuffering
... do some stuff with the socket handle ...
listen h
listen :: Handle -> IO ()
listen h = forever $ do
t <- hGetLine h
let s = init t
putStrLn s
where
forever a = do a; forever a
In pseudo-code what I'd like to have is:
main = do
waitForQuit
... original program ...
waitForQuit :: IO()
option <- getChar
if option == 'q' then
... kill the app ...
else
waitForQuit
You should be able to do this with a Haskell thread, getChar and exit{With,Success,Failure}.
Breaking this down: You get concurrently via
forkIO
. Notice this isn't a separate OS thread, but a Haskell thread which is extremely lightweight. TheexitOnQ
thread needs to get keystrokes without delay - without theNoBuffering
you'd have to hit q-[ENTER]. If the pressed key wasn'tq
(orQ
) then we loop, otherwise we terminate the program via one of the manyexit*
calls.WARNING: It is a very uncommon corner case, but GHC uses GC points as thread scheduling points (has this changed in the past two years?) so if your code is spending significant blocks of time performing lots of pure computations that have zero allocation then you can't use this method to quit (unless you have multiple OS threads via the threaded RTS and an
+RTS -N#
option).You can create new threads with
forkIO
, which takes a chunk of code as an argument. E.g.The quit handler will spend most of its time blocked on
getChar
, but when it wakes up, it can terminate the program, by throwing an exit exception, such as:You may need to compile the program with
ghc -O -threaded
to ensure the program main thread can make progress, while the handler is waiting onq