RFR 9: 8077350 Process API Updates Implementation Review (Due 4/23)

[Paul Sandoz]

On Apr 21, 2015, at 2:57 PM, Roger Riggs <Roger.Riggs at oracle.com> 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
>