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]

My mailer is having trouble hence the empty message …

In any case, nanoTime() is documented as being intended to measure elapsed time as is done here. The implementation using currentTimeMillis() is definitely incorrect as the value return is affected by changing the system whereas nanoTime() has no external reference. Therefore this is at least an improvement if not perfect.

Brian

On Dec 19, 2016, at 5:03 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> 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
>