Hi Roger, On Fri, Apr 17, 2015 at 8:57 PM, Roger Riggs <[email protected]> wrote:
> 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 problem is the audience. Every UNIX system programmer knows about the dangers of pid recycling. Java programmers don't, and your API promises a robustness and simplicity which it unfortunately cannot deliver. No one will expect a ProcessHandle returned by allChildren suddenly to refer to a totally different process. Therefore I also think the dangers should be clearly mentioned in the java doc. Regards, Thomas > 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 >>> >>> >>> >> >
