#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:23 duncan]:
> And similarly:
http://www.linuxselfhelp.com/gnu/glibc/html_chapter/libc_24.html#SEC491
This is the way I've seen it implemented before and as far as I'm aware is
the only non-racy way to get all the exit statuses. We might be able to
define an API which combines the nitty-gritty of handling SIGCHLD &
waiting into a single operation so to hide this complexity from users.
That starts to depart from mimicing POSIX APIs though.
Replying to [comment:21 duncan]:
> If we want to avoid waiting for children that do not belong to
System.Process then we can use WNOWAIT first time and then call it again
if we find the PID was one our ours.
Suppose the second waitable process belongs to System.Process, but the
first waitable process belongs to something else?
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?
Replying to [comment: simonmar]:
> 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.
This is tough to fix within a C signal handler! The # of times a signal
handler might be invoked before the IO manager thread get to run is
unbounded, so you need potentially unbounded memory. But the list of
things you're allowed to do inside a signal handler is pretty short (ref:
[http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html]);
even memory allocation is verboten, so finding a place to buffer that
information somewhere is AFAIK next to impossible.
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)].
This only would work for process-directed signals, not thread-directed
signals, but given GHC's runtime model it seems like all the signals that
users must handle would be process-directed anyway.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2451#comment:24>
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
