ProcessReaper: single thread reaper

[Martin Buchholz]

Peter, thank you very much for your deep analysis.

TIL and am horrified: signals on Unix are not queued, not even if you
specify SA_SIGINFO.  Providing siginfo turns signals into proper "messages"
each with unique content, and it is unacceptable to simply drop some
(Especially when proper queueing seems required for so-called real-time
signals), but at least the Linux kernel does so very deliberately.   45
years later, we are still fighting with unreliable Unix signals...

We can't call waitpid(WAIT_ANY, ) because we can only wait for processes
owned by the j.l.Process subsystem.  We can't override libc functions like
waitpid because the JVM may be a "guest" in some other process.

I don't know of any public examples, but it is reasonable to add a JVM to a
previously pure native code application, similarly to the way tcl or lua is
often used to provide a higher-level safer programming api to native code,
and some programs at Google use this strategy.

What problem are we actually trying to solve?  The army of reaper threads
is ugly, but the inefficiency is greatly mitigated by the use of small
explicit stack sizes.  Redoing the process code is always risky, as we have
already seen in this thread.

Maintaining a single child helper process which spawns all the (grand)child
processes seems reasonable, although it would create a permanent
intermediate entry in the process table (pstree?) which might confuse some
sysadmin scripts.  Is it worth it?