ProcessReaper: single thread reaper (original) (raw)
Martin Buchholz martinrb at google.com
Wed Apr 9 17:05:30 UTC 2014
- Previous message: ProcessReaper: single thread reaper
- Next message: ProcessReaper: single thread reaper
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Here's a practical (but untested) simple improvement: don't set SIGCHLD unless it's already set to SIG_IGN. Please take ownership.
--- a/src/solaris/native/java/lang/UNIXProcess_md.c +++ b/src/solaris/native/java/lang/UNIXProcess_md.c @@ -108,7 +108,8 @@ /* There is a subtle difference between having the signal handler * for SIGCHLD be SIG_DFL and SIG_IGN. We cannot obtain process * termination information for child processes if the signal
* handler is SIG_IGN. It must be SIG_DFL.
* handler is SIG_IGN. Any other value, notably SIG_DFL, is fine.* If there's already a signal handler for SIGCHLD, let it be. * * We used to set the SIGCHLD handler only on Linux, but it's * safest to set it unconditionally.
@@ -124,11 +125,15 @@ * http://www.pasc.org/interps/unofficial/db/p1003.1/pasc-1003.1-132.html */ struct sigaction sa;
- sa.sa_handler = SIG_DFL;
- sigemptyset(&sa.sa_mask);
- sa.sa_flags = SA_NOCLDSTOP | SA_RESTART;
- if (sigaction(SIGCHLD, &sa, NULL) < 0)
JNU_ThrowInternalError(env, "Can't set SIGCHLD handler");
- if (sigaction(SIGCHLD, NULL, &sa) < 0) {
JNU_ThrowInternalError(env, "Can't get SIGCHLD handler");- } else if (sa.sa_handler == SIG_IGN) {
sa.sa_handler = SIG_DFL;sigemptyset(&sa.sa_mask);sa.sa_flags = SA_RESTART;if (sigaction(SIGCHLD, &sa, NULL) < 0)JNU_ThrowInternalError(env, "Can't set SIGCHLD handler");- }
}
static void*
On Wed, Apr 9, 2014 at 10:02 AM, Martin Buchholz <martinrb at google.com>wrote:
On Tue, Apr 8, 2014 at 11:08 PM, Peter Levart <peter.levart at gmail.com>wrote: Hi Martin, As you might have seen in my later reply to Roger, there's still hope on that front: setpgid() + wait(-pgid, ...) might be the answer. I'm exploring in that direction. Shells are doing it, so why can't JDK? It's a little trickier for Process API, since I imagine that shells form a group of processes from a pipeline which is known in-advance while Process API will have to add processes to the live group dynamically. So some races will have to be resolved, but I think it's doable. This is a clever idea, and it's arguably better to design subprocesses so they live in separate process groups (emacs does that), but: Every time you create a process group, you change the effect of a user signal like Ctrl-C, since it's sent to only one group. Maybe propagate signals to the subprocess group? It's starting to get complicated...
- Previous message: ProcessReaper: single thread reaper
- Next message: ProcessReaper: single thread reaper
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]