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]

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 
long time).

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:
>>
>> http://cr.openjdk.java.net/~bpb/8165664/webrev.01/
>>
>> Thanks,
>>
>> Brian
>>
>> On Dec 19, 2016, at 12:08 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>> 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.
>

-- 
- DML