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 at oracle.com
Tue Dec 20 01:03:29 UTC 2016
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:
>>> 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.
> - DML
More information about the nio-dev