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

Martin Buchholz martinrb at google.com
Tue Aug 14 14:47:34 UTC 2018


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.

---

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?

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.




On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <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/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8208715
>
> Thanks, Roger
>
>


More information about the core-libs-dev mailing list