Proper handling of SIGINT/SIGQUIT
|Reported by:||duncan||Owned by:|
|Keywords:||Cc:||bos@…, tibbe, pho@…, v.dijk.bas@…, hvr|
|Type of failure:||Incorrect result at runtime||Test Case:|
|Related Tickets:||#3994,#5766,#7229,#4274,#3318,#1619||Differential Revisions:|
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.
- how we respond to our own calling process when we terminate due to ^C
- 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).
Change History (46)
comment:2 follow-up: ↓ 9 Changed 7 years ago by simonmar
- Component changed from libraries/base to libraries/process
comment:5 Changed 6 years ago by simonmar
- Operating System changed from Multiple to Unknown/Multiple
comment:10 Changed 5 years ago by igloo
- Milestone changed from 6.12.1 to 6.14.1
- Type of failure set to None/Unknown
comment:19 Changed 4 years ago by mcandre
- Architecture changed from Unknown/Multiple to x86
- Operating System changed from Unknown/Multiple to MacOS X
- Type of failure changed from None/Unknown to Incorrect result at runtime
- Version changed from 6.8.2 to 6.12.3
comment:20 Changed 4 years ago by simonmar
- Architecture changed from x86 to Unknown/Multiple
- Operating System changed from MacOS X to Unknown/Multiple
comment:33 Changed 16 months ago by hvr
- Cc hvr added
- Milestone changed from 7.6.2 to 7.8.1
- Operating System changed from Unknown/Multiple to POSIX
- Priority changed from normal to high