#1619: The RTS chokes on SIGPIPE (happens with runInteractiveCommand)
----------------------------+-----------------------------------------------
Reporter: int-e | Owner:
Type: bug | Status: closed
Priority: normal | Milestone: 6.10 branch
Component: Runtime System | Version: 6.7
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Linux |
----------------------------+-----------------------------------------------
Changes (by simonmar):
* status: new => closed
* resolution: => fixed
Comment:
SIGPIPE already causes an exception to be raised, because it occurs as a
side-effect of a `write()` which returns `EPIPE`. So I've come around on
this one and decided we should be just ignoring `SIGPIPE`.
{{{
Wed Jul 9 09:49:16 BST 2008 Simon Marlow <[EMAIL PROTECTED]>
* FIX part of #2301, and #1619
2301: Control-C now causes the new exception (AsyncException
UserInterrupt) to be raised in the main thread. The signal handler
is set up by GHC.TopHandler.runMainIO, and can be overriden in the
usual way by installing a new signal handler. The advantage is that
now all programs will get a chance to clean up on ^C.
When UserInterrupt is caught by the topmost handler, we now exit the
program via kill(getpid(),SIGINT), which tells the parent process that
we exited as a result of ^C, so the parent can take appropriate action
(it might want to exit too, for example).
One subtlety is that we have to use a weak reference to the ThreadId
for the main thread, so that the signal handler doesn't prevent the
main thread from being subject to deadlock detection.
1619: we now ignore SIGPIPE by default. Although POSIX says that a
SIGPIPE should terminate the process by default, I wonder if this
decision was made because many C applications failed to check the exit
code from write(). In Haskell a failed write due to a closed pipe
will generate an exception anyway, so the main difference is that we
now get a useful error message instead of silent program termination.
See #1619 for more discussion.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1619#comment:10>
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
