RFR 9: 8077350 Process API Updates Implementation Review

[Roger Riggs]

Hi David,

On 4/17/2015 2:44 PM, David M. Lloyd wrote:
> On 04/17/2015 11:53 AM, Roger Riggs wrote:
>> 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.
>
> Even with timestamps though, you cannot prevent the PID from being 
> reused in the time window after you verify its timestamp but before 
> you kill it unless it is a direct child process (on UNIX anyway; who 
> knows what Windows does...).  I think that this inevitable race should 
> be mentioned in the docs regardless of whether the timestamp thing is 
> implemented (or doc'd) to prevent unrealistic expectations (the api 
> draft link seems to be dead so I didn't see if it already includes 
> this kind of language).
I can add a note about race conditions to the existing class level
javadoc about process information changing asynchronously.

"Race conditions can exist between checking the status of a process and 
acting upon it."

But I'm still struck by the oddity of Java needing to provide a better 
interface
to processes than the native OS does.  In the native OS, a pid is a pid and
the only handle given to applications.  So both the app and the os need to
be conservative about pid re-use.

The link[1] was broken while I replaced it with an update reflecting the 
recent comments.

Thanks, Roger

[1] http://cr.openjdk.java.net/~rriggs/phdoc/

>
>>> 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
>>
>>
>