#2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by duncan): Yes, I did think about whether it should throw the `UserInterrupt` sync locally or async to the main thread. As you say, the concern is that people do not properly propagate their exceptions from forkIO threads (which I still maintain is a deficiency in our thread system). On the other hand it gives people an opportunity to catch the user interrupt locally if that's what they want to do. If it were not for the annoying problem of forkIO swallowing our exceptions, then I'd say that throwing it locally is really the right thing to do, because by delegating ^C handling to the child process, we really are turning an async exception (being interrupted by a signal) into a sync exception (waiting on process exit, which exits due to a signal). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/2301#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler