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

[Brian Burkhalter]

On 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).
> 
> 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