JDK 9 RFR of 8165664: (ch) sun.nio.ch.SocketAdaptor does not respect timeout in case of system date/time change and blocks

[Martin Buchholz]

On Mon, Dec 19, 2016 at 4:03 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> Two things - IIRC it is possible on some systems for System.nanoTime()
> appear to move backwards (right?), thus you want to change "nanoTime() -
> startTime" constructs to be "max(0, nanoTime() - startTime)" (you can use 1
> instead if you want to always make progress).
>

http://download.java.net/java/jdk9/docs/api/java/lang/System.html#nanoTime--
nanoTime() is supposed to be monotonic.  For j.u.concurrent we once looked
at what it might take to be resilient against non-monotonicity, and gave up.

(It's true that some folks mod their jdk to get cheaper and buggier
nanoTime.)

It's true that in practice it's safer for users to avoid timeouts near
Long.MIN_VALUE or Long.MAX_VALUE.  A 146-year timeout is long enough for
anybody!


> The other thing is to Martin's point, for posterity mainly because I'm
> sure this was just an oversight: you can't use a nanoTime() value (or a
> value based on it) as a deadline because it can wrap around at an
> unspecified point in time, causing deadline comparisons to fail (once you
> wrap around, you'll be < any likely deadline probably for a very long time).
>

We have many "final long deadline"s in j.u.concurrent.


> What you *can* do is get a nanoTime() "snapshot" into a constant field;
> then you can get an "absolute" nanoTime anytime you want (as long as you
> don't expect your program's uptime to exceed about 584 years) by doing:
> max(0, nanoTime() - startTime).


We just assume always nanoTime() - startTime >= 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161220/602a723a/attachment.html>