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
