ProcessReaper: single thread reaper (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Mon Apr 14 17:00:52 UTC 2014

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.

--

More information about the core-libs-dev mailing list