ProcessReaper: single thread reaper

[Peter Levart]

On 03/26/2014 07:09 PM, Martin Buchholz wrote:
> On Wed, Mar 26, 2014 at 11:01 AM, Roger Riggs<Roger.Riggs at oracle.com>wrote:
>
>>   Hi  Martin,
>>
>> My solution to that is to export a public API that can be used
>> by other subsystems that fork processes.  Some peaceful cooperation is
>> required.
>>
> Roger,
>
> I don't think cooperation is possible - your solution must be compatible.
>   Other folks may have written native library code 20 years ago that starts
> a subprocess and then waits for it, not even designed to coexist with a JVM.

SIGCHLD then...

In theory, if registered with sigaction(), the handler could chain the 
old handler so that a 3rd party library code written 20 years ago, 
registering it's own SIGCHLD handler, could co-exist, provided that it 
registers it's handler 1st or that it chains the old handler as well.

The handler already gets all the data we need (from Linux man page):

        * SIGCHLD fills in si_pid, si_uid, si_status, si_utime and 
si_stime, providing information about the child.  The si_pid field is 
the process ID  of  the  child;  si_uid  is  the
          child's real user ID.  The si_status field contains the exit 
status of the child (if si_code is CLD_EXITED), or the signal number 
that caused the process to change state.  The
          si_utime and si_stime contain the user and system CPU time 
used by the child process; these fields do not include the times used by 
waited-for  children  (unlike  getrusage(2)
          and  time(2)).   In  kernels  up to 2.6, and since 2.6.27, 
these fields report CPU time in units of sysconf(_SC_CLK_TCK).  In 2.6 
kernels before 2.6.27, a bug meant that these
          fields reported time in units of the (configurable) system 
jiffy (see time(7)).

This seems to be POSIX api. So it should be present on Solaris/OS X/AIX too?

Regards, Peter