On Apr 21, 2015, at 2:57 PM, Roger Riggs <[email protected]> wrote:
> Hi Paul, > > On 4/21/2015 8:29 AM, Paul Sandoz wrote: >> There are statements in Process about the specified behavior of Processes >> created by ProcessBuilder. That's why I included them in the @implSpec >> clause. If @implSpec is only for the specifics of the method itself then >> where should the behavior of ProcessBuilder created instances be specified? >>>> I think the @implNote you have on Process.onExit about Processes from >>>> ProcessBuilder being more efficient is fine, but that @implNote also >>>> appears to mix stuff that is @implSpec for the method itself. >>> I don't see anything in that @implNote that is spec; just informative. >> Process.onExit triggering waitFor to be called asynchronously in another >> thread seems more spec-like to me (without defining what the executor of the >> CF is, but we can probably specify what it is not i.e. the CF should be >> executed on the f/j common pool). Sorry, I meant to say "i.e. the CF should *not* be ...". >> How could it be otherwise? > The ForkJoinPool is particularly unsuitable for onExit. It has a limited > number of threads > and pretty much assumes that threads do not block indefinitely. Yes. Even if a managed blocker is used with waitFor + timeouts i would advise against using the F/J common pool. > But for this use they block > until the process exits. In my testing, the set of threads gets consumed by > the first set of > onExit calls and then hangs because no more threads are available. > The current implementation creates it own pool and spawn threads as needed, > but that's an implementation detail. > I think the most can be said is that onExit does not block. There's no point > in over specifying > the default implementation of onExit. I am not suggesting over specifying, but currently it feels under specified by not specifying anything :-) Given that is only so much the Process class impl can do regardless of the JDK vendor it seems we could specify something so sub-types can be better informed about whether they should override or not. Paul. > Practically, it does not get used because the JDK > provided subclasses have use a lighter weight mechanism to wait for process > exit and in time > other mechanisms that do not consume a thread are likely. > > Thanks, Roger >
