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
when waiting is not necessary, by using a special "uninitialized" initial
value for remaining nanos, e.g. in FutureTask.awaitDone
long startTime = 0L; // Special value 0L means not yet parked
(I prefer the variable name "startTime")
(j.u.c. code can also be improved)
(there's a pre-existing buglet - we should probably check for overflow when
millis = MAX_VALUE and nanos > 0 (sigh))
(I would reorder clauses to first check the common case millis > 0, then
millis == 0, last the error case millis < 0)
(it's a bad API that millis < 0 is an error)
On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs <roger.ri...@oracle.com> 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
>
>
