#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:26 duncan]:
> Replying to [comment:24 phunge0]:
> > Suppose we call the normal waitpid() instead, and if we find a PID
which isn't ours, we stash the status in a temp buffer, to be returned the
next time someone else calls System.Posix.getAnyProcessStatus?
>
> We must not reap processes that do not belong to us, it's not just the
Haskell API, it's other C libs in the same process as us.
Yep, good point.
Replying to [comment 27: simonmar]:
> Yes, we discussed doing this in the new I/O manager, but the sticking
point is the bit where you say "just block all the signals". We can't
guarantee to do this when new threads might be created by C libraries, or
the Haskell code might itself be a library used by a C client. sigwaitinfo
and signalfd are designed to be used by self-contained processes, not
libraries.
Good point. In any of the "invisible" threads, the signal would not be
blocked, and thus the signal handler would get invoked, which we wouldn't
want. But, could we install a signal handler which noted the signal, and
then blocked the signal from then on? All threads would eventually
accumulate the correct signal masks, even the ones we don't know about
(NB: sigprocmask is signal-safe, I'm assuming pthread_sigmask would be
too).
This is gross, but so are signals ;) You'd still need to communicate over
something like a pipe for the first time that a signal is invoked, before
we had the chance to mask it off; but this'd be a small number of
invocations, potentially signals_with_handlers * n_threads.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:28>
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
