#4162: GHC API messes up signal handlers
---------------------------------+------------------------------------------
Reporter: jcpetruzza | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.14.1
Component: GHC API | Version: 6.12.3
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Changes (by simonmar):
* milestone: => 6.14.1
Comment:
Replying to [comment:1 carlhowells]:
> 1) It's a bug that the GHC api changes signal handlers, and doesn't
change them back when it's finished. The GHC api probably shouldn't even
touch signal handlers. The handler it's installing is part of GHCi, not
the GHC api. Hence I believe GHCi code should be installing it, not the
GHC api.
I sympathise with that view. However, it's not entirely straightforward
to change, because when GHC executes an expression interactively, it
starts a new thread, so Ctrl-C exceptions have to be directed to the
correct thread. There would probably need to be some callback mechanism
from the GHC API back to the client to inform the client that interrupts
need to be directed to a new thread.
I agree we should do this, so let's leave the ticket open.
> 2) Given the current behavior, is it a safe workaround to restore the
previous signal handlers inside the action runGhc is performing, or should
restoring them be delayed until runGhc returns?
restoring the signal handler should be fine. Note we also catch SIGHUP,
SIGTERM, and SIGQUIT, to ensure that GHC cleans up temporary files if any
of these are caught.
> An answer to the latter is what's required for forward progress on hint.
The former is less urgent, but should be considered a bug to some degree
in the GHC api.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4162#comment:3>
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
