ProcessReaper: single thread reaper

[David M. Lloyd]

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