RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug

[Roger Riggs]

Hi Martin,

I updated the webrev with the suggestions.

On 8/14/2018 10:47 AM, Martin Buchholz wrote:
> hi Roger,
>
> 509 if (deadline <= 0) {
> 510 deadline = Long.MAX_VALUE;
> 511 }
>
> This must be wrong.  Nanotime wraparound is normal in this sort of code.
ok, this reader didn't make that assumption
>
> ---
>
> We ought to be able to delegate the fiddling with nanos to 
> TimeUnit.timedWait.
>
> Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
> If not, is there a bug in TimeUnit.timedWait?
That works except on Windows, that does not use wait().

>
> It's good to add a test for this.  I've tried hard in similar tests to 
> avoid sleep and to add variants where the target thread is interrupted 
> before and after starting to wait.  Testing pre-interrupt is easy - 
> the thread can interrupt itself.  
> BlockingQueueTest.testTimedPollWithOffer is an example.
I added a test, using the same logic as the existing tests for the 
Long.MAX_VALUE case

Thanks, Roger

>
>
>
>
> On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
>     Catch wrap around in very large wait times and saturate at
>     Long.MAX_VALUE.
>
>     Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-timeout-8208715/>
>
>     Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8208715
>     <https://bugs.openjdk.java.net/browse/JDK-8208715>
>
>     Thanks, Roger
>
>