Hi Roger,
Retrieving and caching the process start time as soon as ProcessHandle
is instantiated might be a good idea. "destroy" native code would then
use pid *and* start time to check the identity of the process before
killing it.
At least on Linux (/proc/<pid>/stat) and Solaris (/proc/<pid>/status) it
is not necessary to open those special files and read them. Just doing
stat() on them and using the st_mtime will get you the process start
time. I see AIX shares native code with Linux (unix), so perhaps AIX
does the same. Mac OSX and Windows have special calls...
In case OS does not allow retrieving the start time (not owner or
similar), it should be cached as some "undefined" value and treated the
same when destroying. If while obtaining the ProcessHandle *and* while
destorying the process, the start time of the process with a particular
pid is "undefined" then there are two options:
1 - don't kill the process
2 - kill the process
They might actually be no different as the reason of not being able to
retrieve the start time (not owner) might prevent the process from being
killed too, so option 2 could be used to allow killing on any
hypothetical platforms that don't support retrieving start time and it
is no worse than current implementation anyway.
What do you think?
Regards, Peter
On 04/11/2015 08:55 PM, Roger Riggs wrote:
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
