RFR 9: 8077350 Process API Updates Implementation Review

Martin Buchholz martinrb at google.com
Fri May 15 19:31:02 UTC 2015

On Thu, May 14, 2015 at 6:44 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

>> At some point in the development of this API, the implementation
>> introduced the AsyncExecutor to execute synchronous continuations of the
>> onExit() returned CompletableFuture(s). What was the main motivation for
>> this given that:
>> - previously, ForkJoinPoll.commonPool() was used instead that by default
>> possesses some similar characteristics (Innocuous threads when
>> SecurityManager is active)
> The AsyncExecutor also uses InnocuousThreads.
>  - this AsyncExecutor is only effective for 1st "wave" of synchronous
>> continuations. Asynchronous continuations and synchronous continuations
>> following them will still use ForkJoinPoll.commonPool()
> Unfortunately, the common ForkJoinPool assumes that tasks queued to it
> complete relatively
> quickly and free the thread.  It does not grow the number of threads and
> is not appropriate
> for tasks that block for indefinite periods as might be need to wait for a
> Process to exit.
Given that there's no known alternative to tying up a thread to execute
waitpid, there's only small potential benefit to using forkjoinpool.  But
it might be reasonable if you use the ManagedBlocker mechanism to inform
the pool that you are about to block.  I liked the fact that we could use
threads with a small stack size to run waitpid in the special purpose
threadpool, but I don't know how valuable that is in practice.

More information about the core-libs-dev mailing list