ProcessReaper: single thread reaper

[Martin Buchholz]

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...
>
>