JDK 9 RFR of 8165664: (ch) sun.nio.ch.SocketAdaptor does not respect timeout in case of system date/time change and blocks
David M. Lloyd
david.lloyd at redhat.com
Tue Dec 20 00:03:36 UTC 2016
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).
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
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).
On 12/19/2016 04:26 PM, Roger Riggs wrote:
> Looks good.
> $.02, Roger
> On 12/19/2016 5:14 PM, Brian Burkhalter wrote:
>> An updated patch which passes regression tests is here:
>> On Dec 19, 2016, at 12:08 PM, Martin Buchholz <martinrb at google.com>
>>> It's unfortunate the use of int millis timeout is baked into the API.
>>> It's probably best (and traditional) to work with an internal long
>>> nanos field anyways, so there are no millisecond sized roundoff errors.
>>> I sometimes find it easier to understand if I define a deadline
>>> final long deadline = System.nanoTime() + nanosTimeout;
>>> I would do unit conversions using methods from TimeUnit.
More information about the nio-dev