#2451: New signal-handling API
---------------------------------+------------------------------------------
Reporter: simonmar | Owner: simonmar
Type: proposal | Status: new
Priority: high | Milestone: 6.14.1
Component: libraries/unix | Version: 6.8.3
Keywords: | Difficulty: Unknown
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Changes (by phunge0):
* cc: phun...@… (added)
Comment:
Given that the motivation was to share SIGCHLD among several code
paths, I have a few questions:
Suppose both System.Process and some other code has forked children.
What should they do inside their signal handler? Typically they'd want
to call wait(), but that might reap a child which had been forked by the
other API, and then the other handler would never see that its child had
exited. So doesn't the handling of SIGCHLD (i.e. the calling of wait())
have to be a global thing?
The only thing I can think of would be for Process's signal handler to
loop over each child it had forked on it's own, and call waitpid()
instead of wait(), but that's sort of gross. The users of System.Posix
would need to do the same.
Another question: in the docs you posted, you suggest installing a no-op
signal handler to ignore a signal. That's good for 99% of programs, but
some programs really need SIG_IGN instead of a no-op handler. The
reason: signals which have a handler are reset to SIG_DFL after an
exec(), but signals which are SIG_IGN remain ignored. One program which
needs this is [http://en.wikipedia.org/wiki/Nohup nohup]. Seems like
SIG_IGN is deprecated in the new signal API?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:17>
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
