On 04/14/2014 10:54 AM, Peter Levart wrote:
On 04/14/2014 03:50 PM, roger riggs wrote:
Hi Peter,
The new API to handle process trees and processes not spawned by the
Java process
also will need a way to wait for exit status and destroy children so
I'm not sure the
issue goes away. It too will need to co-exist with non-JDK libraries
that spawn and handle
their own children.
Hi Roger,
At some point one has to decide who's responsibility it is to wait on a
child process. If a process is spawned by some native library, one can
expect that it's this library's responsibility to reap that child.
Otherwise you're providing just one half of the story and allowing
conflicts. Spawning a child and waiting on it's exit (or exiting
yourself and leaving the orphan to be handled by init) are two
intrinsically inter-connected actions on UNIX. It's also not possible to
wait on a grand-child.
Only immediate children are the clean-up responsibility of a parent
(regardless of which API was used to spawn them). In that light I
question the need to gracefully destroy anyone besides a direct child.
It might be convenient to be able to forcibly destroy the whole sub-tree
rooted at a particular direct child, but gracefull destruction should be
initiated by sending a TERM signal just to the immediate child. It's
this child's responsibility to do any clean-up needed, including
stopping it's children.
This is exactly what I was getting at.
So I think we need the following capabilities in new API:
- enumerate direct children (regardless of which API was used to spawn
them)
- trigger graceful destruction of any direct child
- non-blocking query for liveness of any direct child
- trigger forcible termination of any direct child and all descendants
in one call
- (optionally: obtain a Process object of any live direct child that was
spawned by Process API)
While the Process API does not provide a satisfactory abstraction of a
direct child process not started by that API, it is not hard to imagine
that a superclass of Process containing a subset of operations, all of
which are relevant to any direct child process, could fulfill the need
with a minimum of API dissonance (i.e. everything excluding the
stream-related methods, including any new graceful termination API methods).
That's my view on the API that provides access to children/ancestors of
JVM and has built-in constraints that prevent users to stray from
recommended practices.
The other possibility would be an API that provides access to any
process on the system. Such API could enumerate all processes on the
system and gracefully/forcibly terminate any process that OS allows (an
API-equivalent for UNIX commands "ps" and "kill"). That would be a
low-level API.
This could be accomplished using a superclass of the aforementioned
superclass which contains only the destroy/terminateNicely/isAlive
methods, but not the exitValue/waitFor kinds of methods.
--
- DML
