Thanks, looks good to me!
On Wed, Nov 19, 2014 at 7:21 AM, roger riggs <roger.ri...@oracle.com> wrote: > Hi, > > Created a new issue and webrev for this correction: > > Please review: > > http://cr.openjdk.java.net/~rriggs/webrev-wait-8065372/ > > Roger > > > On 11/18/2014 11:02 AM, Martin Buchholz wrote: >> >> Here I'm just trying to fix the problem that Object.wait(millis,nanos) >> trivially returns early. >>> >>> That seems overly complex - after checking for valid values of timeout >>> and >>> nanos you simply need: >>> >>> if (nanos > 0) timeout++; >>> >>> to ensure the >= requirement. >> >> Sure, the miminal diff is: >> >> diff --git a/src/java.base/share/classes/java/lang/Object.java >> b/src/java.base/share/classes/java/lang/Object.java >> --- a/src/java.base/share/classes/java/lang/Object.java >> +++ b/src/java.base/share/classes/java/lang/Object.java >> @@ -453,7 +453,7 @@ >> "nanosecond timeout value out of >> range"); >> } >> >> - if (nanos >= 500000 || (nanos != 0 && timeout == 0)) { >> + if (nanos != 0) { >> timeout++; >> } >> >>> But seriously we should just deprecate this version as we're not likely >>> to >>> get any underlying OS mechanisms for doing nanosecond resolution timed >>> blocking actions. >> >> Object.wait(millis, nanos) is an ugly API (I wish for both a public >> and hotspot internal API that simply operated on nanoseconds), but >> it's not totally awful. It's not obvious to me that computing >> advances over the lifetime of the java platform won't allow >> sub-millisecond scheduling, and other APIs that do operate on >> nanoseconds (like Process.waitFor) should call this API. > >
