review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

[Rob McKenna]

Thanks David,

I suspect Alan simply meant that it may be preferable to use 
System.nanoTime to measure the time elapsed in the default 
implementation as opposed to System.currentTimeMillis. I had forgotten 
about the lower resolution of the timer interrupt. I'll revert that 
aspect of the change.

     -Rob

On 20/04/12 02:53, David Holmes wrote:
> Hi Rob,
>
> On 20/04/2012 11:33 AM, Rob McKenna wrote:
>> I've uploaded another webrev to:
>>
>> http://cr.openjdk.java.net/~robm/4244896/webrev.02/
>> <http://cr.openjdk.java.net/%7Erobm/4244896/webrev.02/>
>
> I'll take a look as soon as I have a chance but will be OOTO the rest 
> of today.
>
>> I plan to spend some time over the coming day or two beefing up the test
>> for waitFor (right now its really geared towards destroyForcibly) so I
>> won't guarantee its 100% quite yet. That said, I would like feedback on
>> a couple of points before I proceed:
>>
>> 1) Alan suggested the use of System.nanoTime() so I altered
>> waitFor(long) to allow for a TimeUnit parameter. UnixProcess objects can
>> use Object.wait(long, int) but unfortunately WaitForMultipleObjects (on
>> Windows) only works to millisecond precision.
>
> Object.wait (like Thread.sleep) doesn't honour the nanosecond argument 
> so there is no point trying to use it.
>
> David
> -----
>
>> 2) As Alan noted, there is really no need for isAlive() if people are
>> happy with the idea of waitFor(long, TimeUnit). I'd appreciate any
>> feedback on this aspect of the fix.
>>
>> -Rob
>>
>> On 19/04/12 12:05, Alan Bateman wrote:
>>> On 19/04/2012 01:05, David Holmes wrote:
>>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote:
>>>>>
>>>>> Rob,
>>>>>
>>>>> It looks like waitFor is calling Object.wait(long) without owning
>>>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't
>>>>> waitFor return if the early if the process ends?
>>>>
>>>> Also waitFor doesn't call wait() under the guard of a looping
>>>> predicate so it will suffer from lost signals and potentially
>>>> spurious wakeups. I also don't see anything calling notify[All] to
>>>> indicate the process has now terminated. It would appear that
>>>> wait(timeout) is being used as a sleep mechanism and that is wrong on
>>>> a number of levels.
>>> I assume waitFor(timout) will require 3 distinct implementations, one
>>> for Solaris/Linux/Mac, another for Windows, and a default
>>> implementations for Process implementations that exist outside of the
>>> JDK.
>>>
>>> It's likely the Solaris/Linux/Mac implementation will involve two
>>> threads, one to block in waitpid and the other to interrupt it via a
>>> signal if the timeout elapses before the child terminates. The Windows
>>> implementation should be trivial because it can be a timed wait.
>>>
>>> I assume the default implementation (which is what is being discussed
>>> here) will need to loop calling exitValue until the timeout elapses or
>>> the child terminates. Not very efficient but at least it won't be used
>>> when when creating Processes via Runtime.exec or ProcessBuilder.
>>>
>>> I think the question we need to consider is whether waitFor(timeout)
>>> is really needed. If it's something that it pushed out for another day
>>> then it brings up the question as to whether to include isAlive now or
>>> not (as waitFor without timeout gives us an isAlive equivalent too).
>>>
>>> -Alan.
>>>
>>>
>>>
>>>