#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 phunge0):
Replying to [comment:18 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().
Really? My (vague) understanding is that a single SIGCHLD might be
generated even though multiple children have exited -- i.e. SIGCHLD will
not be queued the way real-time signals are. I see that w/ a test program
which blocks SIGCHILD w/ sigprocmask -- 2 children exit, only one signal
handler gets invoked.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:19>
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
