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

[Roger Riggs]

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). 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.  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.  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