Hi Peter,
Yep, I hadn't gotten to improving that part of the implementation yet.
The threading needs to be revised; System threads and the limited stack
were used currently
to monitor processes (on Linux) but are not suitable for evaluating
CompletionStages.
Switching to some form of Executor as a source of thread is needed.
I was also trying to preserve an option to have a lightweight monitor
of thread liveness that did not require a thread to improve scalability.
That would allow the thread needed for CompletionStage to be created
only if and
when it is needed.
On 2/10/2015 1:17 PM, Peter Levart wrote:
On 02/10/2015 02:02 PM, Peter Levart wrote:
On 02/10/2015 12:35 PM, Peter Levart wrote:
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?
Contemplating on this a little more, then perhaps the singleton-per
pid CompletionStage could be OK if it was a "mirror" of real process
state. For that purpose then, instead of .completableFuture() the
method would be:
public CompletionStage<ProcessHandle> completionStage()
Returns a CompletionStage<ProcessHandle> for the process. The
CompletionStage provides supporting dependent functions and actions
that are run upon process completion.
Returns:
a CompletionStage<ProcessHandle> for the ProcessHandle; the same
instance is returned for each unique pid.
This would provide the most clean API I think, as CompletionStage
does not have any cancel(), complete(), obtrudeXXX() or get()
methods. One could still obtain a CompletableFuture by calling
.toCompletableFuture() on the CompletionStage, but that future would
be a 2nd stage future (like calling .thenApply(x -> x)) which would
not propagate cancel(true) to the process destruction.
The implementation could still use CompletableFuture under the hood,
but exposed wrapped in a delegating CompletionStage proxy.
So the javadoc might be written as:
public abstract void destroy()
Kills the process. Whether the process represented by this Process
object is forcibly terminated or not is implementation dependent. If
the process is not alive, no action is taken.
If/when the process dies as the result of calling destroy(), the
completionStage() completes exceptionally with CompletionException,
wrapping ProcessDestroyedException.
public abstract ProcessHandle destroyForcibly()
Kills the process. The process represented by this ProcessHandle
object is forcibly terminated. If the process is not alive, no action
is taken.
If/when the process dies as the result of calling destroyForcibly(),
the completionStage() completes exceptionally with
CompletionException, wrapping ProcessDestroyedException.
But I'm still unsure of whether it would be better for the
completionStage() to complete normally in any case. Unless the fact
that the process died as a result of killing it could be reliably
communicated regardless of who was responsible for the killing
(either via ProcessHandle.destoroy() or by a KILL/TERMINATE signal
originating from outside the VM).
Peter
Hi Roger,
I checked out your branch in jdk9-sandbox and studied current
implementation.
One problem with this approach (returning a singleton-per-pid
CompletableFuture or CompletionStage) is that current
processReaperExecutor is using threads with very small stack size (32
K) and the returned CompletableFuture could be instructed to append a
continuation that executes synchronously:
CompletionStage.thenApply(), CompletionStage.handle(), etc...
... so user code would execute by such thread and probably get
StackOverflowException...
Yes, a normal stack size is needed.
Also, multiple ProcessHandle objects together with a Process object
for the same pid each return a separate CompletableFuture instance
(not what spec. says). Each of them also spawns it's own thread to
wait for process termination.
Here's a better approach (a diff to your branch):
http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.01/
...it contains a global registry of internal CompletionStage(s) - one
per pid. They are not exposed to users, just used internally (in Unix
ProcessImpl) to execute cleanup and in .completionStage() to append an
asynchronous stage which is returned by the method on each call. So
users appending synchronous continuations to returned CompletionStage
would execute them in a common FJ pool.
Yep that's the idea and should be common across Windows/Unix/MacOSx and
usable with Process and ProcessHandles. I'll take another look.
Thanks, Roger
I haven't tested this yet. It's just an idea to share.
Regards, Peter
