RFR 9: 8077350 Process API Updates Implementation Review

[David M. Lloyd]

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

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

-- 
- DML