On 03/26/2014 07:09 PM, Martin Buchholz wrote:
On Wed, Mar 26, 2014 at 11:01 AM, Roger Riggs<roger.ri...@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
