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
