Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/unix| Version: 6.8.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): I think this is ok, but I'm surprised you didn't also have to export `SignalInfo(..)` and `SignalSpecificInfo(..)` (we'll definitely need these too, otherwise `CatchInfo` and `CatchInfoOnce` aren't very useful). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:35 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API
-+--
Reporter: simonmar | Owner: simonmar
Type: task | Status: new
Priority: highest | Milestone: 7.8.1
Component: libraries/unix| Version: 6.8.3
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by igloo):
* priority: normal = highest
* milestone: _|_ = 7.8.1
Comment:
Before releasing 7.8.1, we should check whether the exports in
{{{
commit 2ab2b4951e4525f34bc32876d40bc3f8fe9fe12d
Author: Ian Lynagh i...@well-typed.com
Date: Wed Oct 31 15:12:28 2012 +
Export CatchInfo,CatchInfoOnce constructors of Handler
}}}
are correct.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:34
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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal| Milestone: _|_ Component: libraries/unix| Version: 6.8.3 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by lewurm): * cc: lewurm@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:33 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: task | Status: new Priority: normal|Milestone: _|_ Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by altaic): * cc: william.knop.nospam@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:32 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: task | Status: new Priority: normal|Milestone: _|_ Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by igloo): * type: proposal = task -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:31 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: normal|Milestone: _|_ Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by dleuschner): * cc: leusch...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:30 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: normal|Milestone: _|_ Component: libraries/unix| Version: 6.8.3 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * priority: high = normal * milestone: 7.0.1 = _|_ Comment: Dropping this to _|_ until I have a chance to work on it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:29 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
Re: [GHC] #2451: New signal-handling API
#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
Re: [GHC] #2451: New signal-handling API
#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 Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2451: New signal-handling API
#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
Re: [GHC] #2451: New signal-handling API
#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:24 phunge0]: 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? Wow, bad wording, let me try to clarify :) The first paragraph is describing a potential problem with what Duncan's proposing, and the second paragraph should read: As an alternative, how about calling the normal waitpid() instead, ... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:25 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
Re: [GHC] #2451: New signal-handling API
#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 duncan): Replying to [comment:24 phunge0]: Suppose the second waitable process belongs to System.Process, but the first waitable process belongs to something else? You're quite right. I had assumed that we could iterate through the list of waitable child processes, but it looks like if we do not reap the first then we never get shown the second. 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. In the worst case we could just call waitpid(pid, WNOHANG) to poll all the pids we are managing. That's a bit ugly when we're managing a lot of processes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:26 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
Re: [GHC] #2451: New signal-handling API
#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 duncan): Perhaps we can just use SIGCHLD as a notification. When we get a SIGCHLD we can assume that there may be multiple children in a waitable state. We can then call waitpid/waitid multiple times, using the WNOHANG flag so it does not block, then we call it repeatedly until there are no more children to wait for. 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. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:21 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
Re: [GHC] #2451: New signal-handling API
#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 duncan): See also the docs for [http://www.opengroup.org/onlinepubs/009695399/functions/wait.html wait()], particular the rationale near the bottom for a discussion of reliably counting child processes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:22 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
Re: [GHC] #2451: New signal-handling API
#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 duncan): And similarly: http://www.linuxselfhelp.com/gnu/glibc/html_chapter/libc_24.html#SEC491 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:23 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
Re: [GHC] #2451: New signal-handling API
#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 Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2451: New signal-handling API
#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:| Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by phunge0): * cc: phun...@… (added) Comment: 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? The only thing I can think of would be for Process's signal handler to loop over each child it had forked on it's own, and call waitpid() instead of wait(), but that's sort of gross. The users of System.Posix would need to do the same. 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? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:17 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
Re: [GHC] #2451: New signal-handling API
#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:| Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by lelf): * cc: anton@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:16 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14 branch Component: libraries/unix| Version: 6.8.3 Keywords:| Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:14 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14 branch Component: libraries/unix| Version: 6.8.3 Keywords:| Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * failure: = None/Unknown Old description: The current API for handling signals in `System.Posix` is lacking in a couple of ways: * it isn't modular: there's no way for a library to install a private signal handler, there is only a singla global handler per signal. * it isn't possible to get hold of the information from `siginfo_t` (#592). I want to propose a new API. This has already undergone a round of changes after discussion with Duncan Coutts, and we ended up with something quite simple. Haddock docs are here: [http://darcs.haskell.org/~simonmar/unix/System-Posix-Signals.html#4] (also attached as `unix-html.tar.gz`). I have working patches to implement this. The old API is still available, and is reimplemented using the new API. Signal handlers installed using the old API will coexist with those installed using the new API. The main motivation for this change was so that I could hook the `SIGCHLD` signal in the `System.Process` library without disturbing users of the `System.Posix` library who might also want to install a `SIGCHLD` handler. Deadline: 1 Aug (2 weeks) New description: The current API for handling signals in `System.Posix` is lacking in a couple of ways: * it isn't modular: there's no way for a library to install a private signal handler, there is only a singla global handler per signal. * it isn't possible to get hold of the information from `siginfo_t` (#592). I want to propose a new API. This has already undergone a round of changes after discussion with Duncan Coutts, and we ended up with something quite simple. Haddock docs are here: [http://www.haskell.org/~simonmar/unix/System-Posix-Signals.html#4] (also attached as `unix-html.tar.gz`). I have working patches to implement this. The old API is still available, and is reimplemented using the new API. Signal handlers installed using the old API will coexist with those installed using the new API. The main motivation for this change was so that I could hook the `SIGCHLD` signal in the `System.Process` library without disturbing users of the `System.Posix` library who might also want to install a `SIGCHLD` handler. Deadline: 1 Aug (2 weeks) -- Comment: Fixed URL to haddock docs in description. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:12 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14 branch Component: libraries/unix| Version: 6.8.3 Keywords:| Difficulty: Unknown Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by bos): * cc: b...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:13 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14 branch Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by PHO): * cc: p...@cielonegro.org (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:11 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14 branch Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * milestone: 6.12.1 = 6.14 branch Comment: No time before 6.12.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:9 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14 branch Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): See also #592 (expose siginfo_t to signal handlers) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:10 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.12.1 Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:8 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: Type: proposal | Status: new Priority: high |Milestone: 6.12.1 Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * milestone: 6.12 branch = 6.12.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:7 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: Type: proposal | Status: new Priority: high |Milestone: 6.12 branch Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * priority: normal = high * milestone: Not GHC = 6.12 branch Comment: We should fix this, although it's not immediately clear to me how at first glance. Perhaps move `Signal` to a portable module? Perhaps even `System.Posix.Process.Internals`? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:6 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API -+-- Reporter: simonmar |Owner: Type: proposal | Status: new Priority: normal|Milestone: Not GHC Component: libraries/unix| Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by golubovsky): The change of Feb 19 (namely in System.Posix.Process.Internals) does not work with Hugs as GHC.Conc is not known to Hugs. As a result, the whole Unix package is skipped while building. Please consider this in future updates. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:5 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
Re: [GHC] #2451: New signal-handling API
#2451: New signal-handling API +--- Reporter: simonmar| Owner: Type: proposal| Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix |Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | +--- Changes (by igloo): * milestone: = Not GHC -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2451#comment:1 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
