#2301: Proper handling of SIGINT/SIGQUIT
------------------------+---------------------------------------------------
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 6.8.2 | Severity: normal
Keywords: | Testcase:
Architecture: Unknown | Os: Multiple
------------------------+---------------------------------------------------
This guide http://www.cons.org/cracauer/sigint.html suggests a couple
things that we should do that we do not currently do.
It comes in two parts.
1. how we respond to our own calling process when we terminate due to
`^C`
1. how we respond to process that we call terminating due to `^C`
The first part is easier. If we decide that we want to terminate in
response to a `^C` signal then it is important that our calling process
knows that. We must kill ourselves using `SIGINT` and not just terminate
via `exit()` otherwise our calling process must assume that we decided to
ignore the `^C`. We should use `killpid(getpid(),SIGINT)`.
Of course we may well want to catch `^C` and do cleanup work by unwinding
all exception handlers etc. It is therefore important to distinguish `^C`
from other exceptions so that when the `^C` exception propagates to the
top level exception handler we have enough information to know to use
`killpid(getpid(),SIGINT)` rather than just `exit(1)`. So we should add an
`Interrupted` case to the `Exception` type.
How we respond to `^C` while running sub-processes is more subtle. If we
are delegating interaction with the user via the controlling terminal then
we should also delegate the decision about how to respond to `^C`. Some
child processes will also want to take cleanup action on `^C` or ignore it
completely (eg ghci) so it is not right for us the parent process to catch
`^C` and decide what to do. So where we are delegating the decision we
should ignore `^C`.
When we wait for a child process to terminate and discover that it exited
due to `SIGINT` then at that moment we should respond in the same way as
if we ourselves had received a `^C`. A sensible default might be to send
the `Interrupted` exception to every thread in the system, or at least to
the main thread. A haskell program can always change the response to `^C`
by using `installHandler` (eg for an interactive REPL program like ghci).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2301>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
