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

Thank you Roger! The fix addresses the issue with System.currentTimeMillis() and returning early from sleep()/join(), so it looks good! I think it's better to wrap the line 1304 up to improve readability. Maybe import j.u.c.TimeUnit.NANOSECONDS, so that `TimeUnit.' could be omitted? No fu

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

Hi Ivan, Thanks for the suggestion. Webrev updated:    http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ Thanks, Roger On 9/4/2018 3:38 PM, Ivan Gerasimov wrote: Thank you Roger! I'm not sure if it plays any significant role, but an unnecessary call to nanoTime() after wait(de

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

On Tue, Sep 4, 2018 at 12:02 PM, Roger Riggs wrote: > >> One sharp corner is that wait(0) waits forever, and TimeUnit conversion >> truncates. You can probably avoid those problems via TimeUnit.timedWait. >> >> Not trivial since a long cannot hold the combined time of millis(long) > and nanos (l

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

Thank you Roger! I'm not sure if it plays any significant role, but an unnecessary call to nanoTime() after wait(delay) could be avoided with the code like this: if (millis > 0) { if (isAlive()) { final long startTime = System.nanoTime(); long delay = millis

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

Hi Martin, Ivan, Thanks for the suggestions. Update in place: http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ On 8/29/2018 5:36 PM, Martin Buchholz wrote: Thanks for taking this on. Wait loops are notoriously hard to get right... One sharp corner is that wait(0) waits forever,

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

Thanks for taking this on. Wait loops are notoriously hard to get right... One sharp corner is that wait(0) waits forever, and TimeUnit conversion truncates. You can probably avoid those problems via TimeUnit.timedWait. In code like this in j.u.c. we try to optimize away the call to nanoTime whe

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

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, 50), which was also not quit

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

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