JEP 102 Process Updates revised API draft

[Peter Levart]

On 02/13/2015 04:34 PM, Peter Levart wrote:
> On 02/13/2015 04:18 PM, David M. Lloyd wrote:
>>
>> 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

Well, the above suggestion has a drawback too. Currently (with latest 
implementation), waiting on process exit is done by a small-stack thread 
and when process exits, this thread submits a task to the system FJ pool 
executor that executes user code in normal-stack thread. With above 
suggestion, the behaviour would be different depending on platform:

- Windows: waiting on process exit would be executed by normal-stack 
thread which would also run user code afterwards.
- UNIX: waiting on process exit would be executed by small-stack thread 
+ there would be another normal-stack thread occupied with waiting on 
small-stack thread to signal completion.

Consumption of occupied threads, while waiting on process exits, would 
be doubled on UNIX and normal-stack threads would be occupied on both 
platforms for waiting.

Current code is more effective in this respect.

Peter