JEP 102 Process Updates revised API draft

[Roger Riggs]

Hi Peter, et.al.,

I have no particular issue with adding waitForUninterruptibly but it 
does not
help with the lack of scalability when handling many processes.
It requires a thread to do the waiting whether from a specific caller or 
a thread pool

The intent of proving a Future/CF was to allow the implementation the 
choice of
how to wait for termination including those mechanisms that do not 
require dedicating
a thread to the  monitoring of termination and taking an action thereafter.
On Windows for example, WaitForMultipleObjects can be used to multiplex 
the waiting.

With Lambda providing the behavior to CF, the lambda can capture the 
reference
to the Process[Handle] without relying on the generic type of the CF.

Process p = ...;
CompletableFuture<ProcessHandle> cf = p.completableFuture();
cf.thenRunAsync(  () -> {int exitValue = p.getExitValue(); ....   })

Or using CompletableFuture<Void> would force the developer to capture 
the Process[Handle]
reference as needed.

Another alternative is a simple method 
onTermination(Consumer<ProcessHandle> consumer)
that makes it easy to use lambdas to provide the behavior.  The 
implementation
can use the same Thread pool as CF to provide the thread. It has the same
threading issues as CF but with less complexity in the interface.

An alternative without an argument would be onTerminate(Runnable 
runnable) and
it would generally be the case that the lambda would need to have a 
binding for the
reference to the Process/ProcessHandle.

Roger

On 2/13/2015 10:34 AM, Peter Levart wrote:
> On 02/13/2015 04:18 PM, David M. Lloyd wrote:
>> On 02/13/2015 09:15 AM, Peter Levart wrote:
>>> On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>>>>> >It*is*  inconvenient for the user to have to use wildcards in 
>>>>> specifying types:
>>>>> >
>>>>> >CompletableFuture<? extends Process> cf = 
>>>>> process.completableFuture();
>>>>> >
>>>>> >...but it doesn't hinder the use of above 'cf' quite so much as 
>>>>> 'len' in List example above, since 'T' in CompletableFuture<T> is 
>>>>> used mostly in co-variant positions. The only methods that use it 
>>>>> in contra-variant positions are:
>>>>> >
>>>>> >cf.getNow(?);
>>>>> >cf.complete(?);
>>>>> >cf.obtrudeValue(?);
>>>>> >
>>>> What about the methods with a parameter type of:
>>>>
>>>>    CompletionStage<? extends T>
>>>>
>>>> such as applyToEither and acceptEither?
>>>>
>>>> Paul.
>>>
>>> Oh, I see.
>>>
>>> That's a problem, yes. And these two methods are actually very 
>>> useful in
>>> the context of processes - waiting for 1st of two processes to finish.
>>>
>>> So the signature can only be the following:
>>>
>>>      CompletableFuture<ProcessHandle> completableFuture();
>>
>> I hesitate to mention it, but as someone who has been frustrated by 
>> this same problem on numerous occasions I feel I must suggest that 
>> maybe... having a completableFuture method should just be dropped?  A 
>> user should be able to implement it themselves fairly easily, right?  
>> And they'd be able to sidestep problems like stack size and so on by 
>> managing their own threads.
>>
>
> That's a good idea. If the following two methods were added to 
> Process[Handle]:
>
>     public class ProcessHandle {
>         public ProcessHandle waitForUninterruptibly();
>     }
>
>     public class Process extends ProcessHandle {
>         @Override
>         public Process waitForUninterruptibly();
>     }
>
> One could get CompletableFuture(s) simply by:
>
>         ProcessHandle ph = ...;
>
>         CompletableFuture<ProcessHandle> phf = 
> CompletableFuture.supplyAsync(ph::waitForUninterruptibly);
>
>         Process p = ...;
>
>         CompletableFuture<Process> pf = 
> CompletableFuture.supplyAsync(p::waitForUninterruptibly);
>
>
> Peter