Hi Martin,
I updated the webrev with the suggestions.
On 8/14/2018 10:47 AM, Martin Buchholz wrote:
hi Roger,
509 if (deadline <= 0) {
510 deadline = Long.MAX_VALUE;
511 }
This must be wrong. Nanotime wraparound is normal in this sort of code.
ok, this reader didn't make that assumption
---
We ought to be able to delegate the fiddling with nanos to
TimeUnit.timedWait.
Does it work to simply call NANOSECONDS.timedWait(remainingNanos) ?
If not, is there a bug in TimeUnit.timedWait?
That works except on Windows, that does not use wait().
It's good to add a test for this. I've tried hard in similar tests to
avoid sleep and to add variants where the target thread is interrupted
before and after starting to wait. Testing pre-interrupt is easy -
the thread can interrupt itself.
BlockingQueueTest.testTimedPollWithOffer is an example.
I added a test, using the same logic as the existing tests for the
Long.MAX_VALUE case
Thanks, Roger
On Tue, Aug 14, 2018 at 7:00 AM, Roger Riggs <roger.ri...@oracle.com
<mailto:roger.ri...@oracle.com>> wrote:
Please review a fix for Process.waitFor(Long.MAX_VALUE,MILLIS).
Catch wrap around in very large wait times and saturate at
Long.MAX_VALUE.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-timeout-8208715/
<http://cr.openjdk.java.net/%7Erriggs/webrev-timeout-8208715/>
Issue:
https://bugs.openjdk.java.net/browse/JDK-8208715
<https://bugs.openjdk.java.net/browse/JDK-8208715>
Thanks, Roger
