RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock (original) (raw)

Ivan Gerasimov ivan.gerasimov at oracle.com
Wed Aug 29 21🔞19 UTC 2018


Hi Roger!

This is of course a corner case, but now if you call thread.join(Long.MAX_VALUE, 1) you'll get IllegalArgumentException("timeout value is negative"); And the same with sleep(long, int).

Before the fix, the same would happen with join(Long.MAX_VALUE, 500000), which was also not quite expected.

Would it make sense to do if (nanos > 0 && millis < Long.MAX_VALUE) just for extra accuracy?

With kind regards, Ivan

On 8/29/18 1:06 PM, Roger Riggs wrote: > Please review changes for: >> 8098798: Thread.join(ms) on Linux still affected by changes to the > time-of-day clock > Use System.nanoTime to compute any remaining delay >> 8210004: Thread.sleep(millis, nanos) timeout returns early > Avoid an early return by rounding the milliseconds up if there > are any nanoseconds as was done in Object.wait(ms, ns). >> (If its not appropriate to do the two reviews together, I can split > them). >> Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ >> Thanks, Roger >>

With kind regards, Ivan Gerasimov



More information about the core-libs-dev mailing list