Hi Peter,
On 4/17/2015 4:05 AM, Peter Levart wrote:
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.
Yes, though it does raise a question about how to specify PH.equals().
Either the start time is explicitly
mentioned (and is repeatable and testable) or it is vague and refers to
some implementation
specific value that uniquely identifies the process; and is less testable.
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...
That is less expensive. But opening /proc/<pid>/stat is necessary for
allChildren to get
and filter on the parent and can provide the starttime as well.
stat would be useful for allProcesses which does not need the parent.
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 destroying 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.
Destroy is a best-effort method; it is not guaranteed to result in
termination, though
the docs are a bit weak on this point.
I'd go for option 2, anyone using the API is looking for results on
processes they
already know something about (mostly), so there's no reason to be
particularly
conservative about. If the caller is trying to be more conservative,
they can maintain
their own extra information about the processes they are managing.
What do you think?
I'd like to pick this up as a separate change, and get the current one
in first.
Roger
