JEP 102 Process Updates revised API draft

[Peter Levart]

On 02/10/2015 12:25 AM, Roger Riggs wrote:
> Hi,
>
> After a protracted absence from working on JEP 102, the updated API draft
> provides access to process hierarchies and individual process 
> information;
> as permitted by the OS. The relationship between Process and 
> ProcessHandle
> is clarified and the security model validated.
>
> Both Processes and ProcessHandles can be monitored using 
> CompletableFuture
> for termination and to trigger additional actions on Process exit.
> Information about processes includes the total cputime, starttime, user,
> executable, and arguments.
>
> Please review and comment:
>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> Thanks, Roger
>
>
>
>
Hi Roger,

Great to see progress on this.

Here are my comments:

ProcessHandle.{allProcesses,allChildren,children} return 
Stream<ProcessHandle>. This is convenient if one wants to use Stream 
API, but a little more inconvenient and perhaps with additional overhead 
if one doesn't. Since all those methods return a "snapshot", I can 
imagine that internally, there is a collection built from this snapshot. 
So it would be most appropriate to return a List<ProcessHandle>. One can 
always continue the expression by appending .stream()..., but on the 
other hand if one wants to .collect(toList()), additional copying is 
introduced.

ProcessHandle.completableFuture().cancel(true) forcibly destorys 
(destroyForcibly()) the process *and* vice versa: destory[Forcibly]() 
cancels the CompletableFuture. I don't know if this is the best way - 
can't decide yet. In particular, in the implementation it would be hard 
to achieve the atommicity of both destroying the process and canceling 
the future. Races are inevitable. So it would be better to think of a 
process (and a ProcessHandle representing it) as the 1st stage in the 
processing pipeline, where ProcessHandle.completableFuture() is it's 
dependent stage which tracks real changes of the process. Which means 
the behaviour would be something like the following:

- ProcessHandle.destroy[Forcibly]() triggers destruction of the process 
which in turn (when successful) triggers completion of 
CompletableFuture, exceptionally with CompletionException, wrapping the 
exception indicating the destruction of the process 
(ProcessDestroyedException?).

- ProcessHandle.completableFuture().cancel(true/false) just cancels the 
CompletableFuture and does not do anything to the process itself.

In that variant, then perhaps it would be more appropriate for 
ProcessHandle.completableFuture() to be a "factory" for 
CompletableFuture(s) so that each call would return new independent 
instance.

What do you think?

Regards, Peter