On 20/11/2014 1:21 AM, roger riggs wrote:
Hi,
Created a new issue and webrev for this correction:
Please review:
http://cr.openjdk.java.net/~rriggs/webrev-wait-8065372/
Fine by me.
Thanks,
David
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.
