#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: | Testcase:
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonmar):
Replying to [comment:17 phunge0]:
>
> 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?
No - the SIGCHLD handler gets passed the pid of the process that died, so
it can decide whether this process belongs to someone else, and if not
reap it using waitpid().
> 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?
Yes, this is something I'll need to look into.
Right now the new API is on ice, as I've been busy with other things. The
main remaining problem is that signal delivery isn't reliable enough in
the currently implementation, because the pipe used to communicate with
the IO manager thread can fill up and signals can be dropped, so we need
some way to handle that.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
