#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:24 phunge0]:
> One suggestion: just block all the signals that you need to handle, and
spawn a thread which waits for them using sigwaitinfo (more detail:
[http://www.linuxjournal.com/article/2121?page=0,1])? Since you're now in
thread i.s.o. signal context, you can do whatever you want. On newer linux
you could also wait directly in the IO manager using
[http://www.kernel.org/doc/man-pages/online/pages/man2/signalfd.2.html
signalfd(2)].
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:27>
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
