Process trees and termination (original) (raw)

roger riggs roger.riggs at oracle.com
Thu Jun 26 14:02:35 UTC 2014

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

More information about the core-libs-dev mailing list