Hi Thomas,
Thanks for the comments.
On 4/11/2015 8:31 AM, Thomas Stüfe 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?
Earlier versions included a killProcess tree method but it was
recommended to leave
the exact algorithm to kill processes to the caller.
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?
Unless there is an extended time between getting the children and
destroying them the pids will still be valid.
The technique of caching the start time can prevent that case; though it
has AFAIK not been a problem.
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.
Of course, the best case is for an application to spawn and manage its
own processes
and handle there proper termination.
The use cases for children/allChildren are focused on
supervisory/executive functions
that monitor a running system and can cleanup even in the case of
unexpected failures.
All management of processes is subject to OS limitations, if the PID
were from a completely
different process tree, the ordinary destroy/info functions would not be
available
unless the process was running as a privileged os user (same as any
other native application).
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.
The caching of startTime can remove the ambiguity.
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.
Earlier discussions of process termination and exit value reaping
considered
using process groups but it became evident that the Java runtime needed to
be very careful to not interfere with processes that might be spawned and
controlled by native libraries and that process groups would only increase
complexity and the interactions.
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()".
Thanks, Roger
Kind Regards, Thomas
On Thu, Apr 9, 2015 at 10:00 PM, Roger Riggs <roger.ri...@oracle.com
<mailto: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/
<http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/>
The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph
<http://cr.openjdk.java.net/%7Erriggs/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
<mailto: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/
<http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/>
The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph
<http://cr.openjdk.java.net/%7Erriggs/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