On Mon, Nov 17, 2014 at 9:02 PM, David Holmes <david.hol...@oracle.com> wrote:
> Hi Martin,
>
> On 18/11/2014 2:49 PM, Martin Buchholz wrote:
>>
>> Hi David,
>>
>> I'm still hoping to persuade you (and others) to fix the long-standing
>> return-early bug in Object.wait.
>
>
> Are you referring to the low level mechanics or specifically to the
> nanosecond version below?
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.
