Process trees and termination

[roger riggs]

Hi David,

On 6/25/2014 6:05 PM, David M. Lloyd wrote:
> On 06/25/2014 04:52 PM, roger riggs wrote:
>> Hi,
>>
>> The next step for JEP 102, Process API Updates is to provide an API to
>> enumerate the hierarchy of processes and to be able to terminate a
>> process tree.
>>
>> This draft javadoc <http://bussund0416/%7Erriggs/pdoc/>update [1] 
>> includes:
>>   - ProcessHandle class to provide handles to processes, their children,
>>      parent, process id and liveness
>>   - Process extends ProcessHandle and inherits the new behaviors
>>   - Method destroyProcessTree() terminates a process tree
>>
>> Additional functions related to termination and information about 
>> processes
>> will be added in a later update.
>>
>> Comments appreciated, Roger
>
> I still have a not-great feeling about the lack of atomicity inherent 
> in these operations.  At least when you're dealing with direct child 
> processes (on UNIX-likes), there is some measure of control, in that a 
> process is zombified until reaped by wait() and friends.
The forcible termination implementation sends a kill signal and relies 
on the OS to finish the job.
Perhaps the semantics need to be clearer that the method does not ensure 
the
process has been cleaned up. The isAlive can be used to verify.

>
> Also I have a much higher level of concern about destroyProcessTree(), 
> which I don't think has any place in this API.  Control of any process 
> belongs solely with their parent (or PID 1), in my opinion.
That is the preferable situation as raised in earlier threads.
However, in practice, if the parent dies, it is not always the case that 
PID 1
reaps them and they hang around.

>
> Those concerns aside, what about making the allChildren() and 
> allProcesses() methods lazy in some way?
Either using the old Enumeration pattern or perhaps some kind of Queue 
that returned
instances until it could not find any new unique processes.
They might be an issue with termination if processes were being created
faster than the application was processing them.
A bit pathological case perhaps but the application would not be aware
it was not keeping up and might never finish.

The snapshot of processes from the OS is pretty clean in a single native 
call.

With the snapshot approach the application could re-do the snapshot and
know there were new processes.

Thanks, Roger