RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug (original) (raw)

Roger Riggs Roger.Riggs at Oracle.com
Tue Aug 14 16:48:06 UTC 2018

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.MAXVALUE; 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.Riggs at oracle.com_ _<mailto:Roger.Riggs at oracle.com>> wrote: Please review a fix for Process.waitFor(Long.MAXVALUE,MILLIS). Catch wrap around in very large wait times and saturate at Long.MAXVALUE. 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

More information about the core-libs-dev mailing list