On Thu, May 14, 2015 at 6:44 AM, Roger Riggs <roger.ri...@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.
