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