RFR 9: 8077350 Process API Updates Implementation Review

[Thomas Stüfe]

p.s.

Note that using allChildren() to kill process trees has a second problem,
even without PID recycling: the PID list it returns may not be complete
once you come around to use it.

Imagine a process tree with some runaway process forking below you
constantly. You want to kill the complete process tree, and do this fast.
Iterating over /proc to collect PIDs, returning this list to java to then
start processing it may be way to slow for this case. You'd end up with a
lot of zombies.

Again, process groups were made for problems like this.

On Sat, Apr 11, 2015 at 2:31 PM, Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi Roger,
>
> I have a question about getChildren() and getAllChildren().
>
> I assume the point of those functions is to implement point 4 of JEP 102
> ("The ability to deal with process trees, in particular some means to
> destroy a process tree."), by returning a collection of PIDs which are the
> children of the process and then killing them?
>
> However, I am not sure that this can be implemented in a safe way, at
> least on UNIX, because - as Martin already pointed out - of PID recycling.
> I do not see how you can prevent allChildren() from returning PIDs which
> may be already reaped and recyled when you use them later. How do you
> prevent that?
>
> Note even if your coding is bulletproof, that allChildren() will also
> return PIDs of sub processes which are completely unrelated to you and
> Process.java - they could have been forked by some third party native code
> which just happens to run in parallel in the same process. There, you have
> no control about when it gets reaped. It might already have been reaped by
> the time allChildren() returns, and now the same PID got recycled as
> another, unrelated process.
>
> If I am right, it would not be sufficient to state "There is no guarantee
> that a process is alive." - it may be alive but by now be a different
> process altogether. This makes "allChildren()" useless for many cases,
> because the returned information may already be obsolete the moment the
> function returns.
>
>
Of course I may something missing here?
>
> But if I got all that right and the sole purpose of allChildren() is to be
> able to kill them (or otherwise signal them), why not use process groups?
> Process groups would be the traditional way on POSIX platforms to handle
> process trees, and they are also available on Windows in the form of Job
> Objects.
>
> Using process groups to signal sub process trees would be safe, would not
> rely on PID identity, and would be more efficient. Also way less coding.
> Also, it would be an old, established pattern - process groups have been
> around for a long time. Also, using process groups it is possible to break
> away from a group, so a program below you which wants to run as a demon can
> do so by removing itself from the process group and thus escaping your kill.
>
> On Windows we have Job objects, and I think there are enough similarities
> to POSIX process groups to abstract them into something platform
> independent.
>
> The only problem I think is that the API would have somehow to be changed.
> Either by directly reflecting the use of process groups, or at least by
> removing allChildren() and replacing it with something like
> "killAllChildren()" or "signalAllChildren()".
>
> Kind Regards, Thomas
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Apr 9, 2015 at 10:00 PM, Roger Riggs <Roger.Riggs at oracle.com>
>  wrote:
>
>> Please review the API and implementation of the Process API Updates
>> described inJEP 102 <https://bugs.openjdk.java.net/browse/JDK-8046092>.
>> Please  review and comment by April 23rd.
>>
>> The recommendation to make ProcessHandle an interface is included
>> allowing the new functions to be extended by Process subclasses.
>> The implementation covers all functions on Unix, Windows, Solaris, and
>> Mac OS X.
>>
>> The API doc: http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph
>>
>> Issue: JDK-8077350 <https://bugs.openjdk.java.net/browse/JDK-8077350>
>> Process API Updates Implementation
>>
>> The code is in the jdk9 sandbox on branch JDK-8046092-branch.
>>
>> Please review and comment, Roger
>>
>
>
> On Thu, Apr 9, 2015 at 10:00 PM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Please review the API and implementation of the Process API Updates
>> described inJEP 102 <https://bugs.openjdk.java.net/browse/JDK-8046092>.
>> Please  review and comment by April 23rd.
>>
>> The recommendation to make ProcessHandle an interface is included
>> allowing the new functions to be extended by Process subclasses.
>> The implementation covers all functions on Unix, Windows, Solaris, and
>> Mac OS X.
>>
>> The API doc: http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph
>>
>> Issue: JDK-8077350 <https://bugs.openjdk.java.net/browse/JDK-8077350>
>> Process API Updates Implementation
>>
>> The code is in the jdk9 sandbox on branch JDK-8046092-branch.
>>
>> Please review and comment, Roger
>>
>
>