delay(MAX_VALUE) breaks with non-monothonic clocks #1312
Assignees
Labels
Comments
elizarov
added a commit
that referenced
this issue
Jul 6, 2019
There are two levels of protection: * All delays for longer than Long.MAX_VALUE/2 nanos (~146 years) are considered to be "infinite", so adding then to the heap queue is not even attempted, thus minimizing a number of cases when we have "close to wraparound" times in there. This also works as optimization reducing effort, so delay(Long.MAX_VALUE) works faster. * The invariant for delayed task's in the heap queue is defined so that all scheduled tasks are at most Long.MAX_VALUE nanos apart, thus always guaranteeing that they can be compared in a stable way despite wraparounds in time. The invariant is maintained by keeping "last observed nowTime" and making sure that all scheduled tasks in the queue are "after" this time. Fixes #1312
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's an circumstantial evidence that some systems may have non-monotonic implementation of
System.nanoTime(). In this case the current implementation fordelay(Long.MAX_VALUE)corrupts internal scheduling data structures and causes further delays to behave erratically.The text was updated successfully, but these errors were encountered: