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.ri...@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.ri...@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
>
