Thanks for the huge effort. I did a superficial review and it seems pretty good. Of course, changing the Process good is high risk and some things will probably need fixup later.
On Unix, you seem to be identifying ProcessHandles by their pid. What are you going to do about the problem of misidentifying Unix processes whose pid got recycled? If you spin up a thread to call waitpid as soon as you create the ProcessHandle, the window is very short (and OSes avoid recycling pids immediately) so that's pretty safe, but it wastes a thread for each ProcessHandle! I don't have a good answer. Maybe record the start time of the process, where available? + } else if (siginfo.si_code == CLD_KILLED || siginfo.si_code == CLD_DUMPED) { Using siginfo probably won't work under load because multiple signals arriving at the same time are coalesced into one, at least on Linux. Unix signals are sadly totally broken. -- It seems you don't support sending arbitary signals, which is a little sad. On Thu, Apr 9, 2015 at 1:00 PM, Roger Riggs <roger.ri...@oracle.com> wrote: > Please review the API and implementation of the Process API Updates > described inJEP 102 <https://bugs.openjdk.java.net/browse/JDK-8046092>. > Please review and comment by April 23rd. > > The recommendation to make ProcessHandle an interface is included > allowing the new functions to be extended by Process subclasses. > The implementation covers all functions on Unix, Windows, Solaris, and Mac > OS X. > > The API doc: http://cr.openjdk.java.net/~rriggs/ph-apidraft/ > > The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph > > Issue: JDK-8077350 <https://bugs.openjdk.java.net/browse/JDK-8077350> > Process API Updates Implementation > > The code is in the jdk9 sandbox on branch JDK-8046092-branch. > > Please review and comment, Roger >