RFR 9: 8077350 Process API Updates Implementation Review
Roger.Riggs at Oracle.com
Wed May 20 16:03:49 UTC 2015
yes, your patch does reduce the code quite a bit except where the
complexity is needed.
The commonPool does have a soft limit (256/system property) on the
compensating processes it will start.
That limit would only come into play for subclasses of Process that did
not properly override onExit to delegate to the underlying builtin
So, probably not a big risk.
It might be desirable to put the loop and exception handling inside the
but the difference is only in the creation of additional inner class
instances in the case
On 5/20/2015 4:39 AM, Peter Levart wrote:
> Hi Roger,
> I looked at Martin's idea and I think that we don't need the
> AsyncExecutor at all (it already sounds like I hate it ;-). Using
> ManagedBlocker, a ForkJoinPoll can compensate and grow it's pool as
> needed when Process.waitFor() blocks. So we could leverage this
> feature and simplify things even further:
> Passing a commonPool() to xxxAsync() methods is unneeded as the
> default is exactly the same. If CompletableFuture ever gets a feature
> to specify a default Executor for all it's descendants, then we can
> revisit this if needed.
> What do you think?
> Regards, Peter
> On 05/19/2015 10:15 PM, Roger Riggs wrote:
>> The webrev, javadoc, and specdiffs have been updated to address
>> recent recommendations:
>> Please review and comment:
>> http://cr.openjdk.java.net/~rriggs/webrev-ph/ (May 19)
>> http://cr.openjdk.java.net/~rriggs/ph-apidraft/ (May 19)
>> Diffs of the spec/javadoc from previous draft:
>> Thanks, Roger
More information about the core-libs-dev