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
