RFR 9: 8077350 Process API Updates Implementation Review

[Martin Buchholz]

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.Riggs at 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
>