JEP 102 Process Updates revised API draft

[Roger Riggs]

Hi Peter,

On 2/10/2015 6:35 AM, Peter Levart wrote:
> 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.
I've been pulled both ways by various folks here also.
Both Streams and Collections are easily converted to the other.
The internal snapshot is an array of int pid's;  with the Stream, the 
creation of ProcessHandles can
be delayed until they are needed, if they are needed.
>
> 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.
Atomicity is provided by CompletableFuture, it handles the atomicity of 
updating its state.
If cancelled, there is no useful information or synchronization is 
needed from the (dieing) Process;
the CompletableFuture state/status is cancelled.
> 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?).
Maybe thinking along the similar lines; Process and Future are loosely 
coupled;
A process exiting, regardless of whether  it was killed by some entity 
in the system
or the Java API should complete the Future.
For a Process, the exitStatus is available and could be used to modify 
the normal vs exceptional completion.
But for an arbitrary ProcessHandle, the process may not have been 
spawned by this process;
in that case the exit status is not available (see previous long 
discussions about reaping).
Also, the exit status may not be a reliable indication of success vs 
failure of the process.
So the best that can be reported is that the Process is terminated and 
the Future is completed (normally).

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

My model was that the CompletableFuture from ProcessHandle is a proxy 
for the process itself.
It is an abstraction for the Process that is independent of the 
implementation (as a Process).
It looks just like any other stage in the tree of CompletionStages.
The application that spawns the Process can control what it exposes as 
the CompletableFuture
it can expose the root or create another Completable future to hang 
other operations on.

>
> 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?

I'm not sure which model is more useful to the application/library.
The implementation may be simpler if it only has to keep track of a 
single CompletableFuture
instead of a set but decoupling may be simpler to model.

Thanks, Roger
>
> Regards, Peter
>