ProcessReaper: single thread reaper

[Martin Buchholz]

SIGCHLD should be chained to ambient signal handlers, as other handlers in
the JDK do.  A general improvement would be supporting arbitrary
user-defined signal handlers pre-existing when the JVM is started.

In the current implementation, the code that sets the signal handler for
SIGCHLD to SIG_DFL should probably have first checked whether the inherited
value is SIG_IGN.

As for relying on SIGCHLD correctly reporting info in siginfo, you are
replacing a time-immemorial API with a relatively recent one.  I would
expect portability problems.

Latest standard seems to be:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html
There's enough wiggle room for implementations to say they're
standard-compliant and not give you the data you want.



On Wed, Mar 26, 2014 at 12:07 PM, Peter Levart <peter.levart at gmail.com>wrote:

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