Elena Semukhina wrote:
On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
> yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
> issue
> for that. I saw this failure quite long ago but cannot reproduce it
today
> trying different platforms/EMs. When the test failed, it reported that
> actual wait time is less than required.
>
> The spec for join() reads: "Waits at most millis milliseconds plus
> nanosnanoseconds for this thread to die. " There is an obvious
> misprint here:
> there should be "at least" but not "at most" and this was mentioned in
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368
>
> On the other hand, in classlib ThreadTest I saw that they agree with
> Thread.sleep(1000) duration >= 800 and join(100, 999999) duration <=
300.
>
> Can the current DRLVM guarantee that it does not exit join() earlier
than
> expected?
> If not, we should make the test more tolerable to timing.
There is also an unstable ObjectTest.testWaitlongint which fails once in
a while (about once in 50 - 100 runs). It also seems to wait a bit less
than required. I think there is also a bug in the test, nanos should be
500000, not 500. But fixing this doesn't help, test still fails on
windows.
Gregory, why do you think this is a bug? nanos can be any value between 0
and 999999. Actually there is a bug in thread_native_condvar.c which
Yes it can. But I think that comparison at the end of the test that
"finish - start + 1 > millis" mean that it should be 1 more millisecond
of waiting. To do this it was intended to wait for 500 and a half =
500.5 milliseconds, which means that nanos should be 500000, not 500.
Correct my if I am wrong about the original test intension.
ignores
any nanos < 1000 when converting them to microseconds.
The spec for Object.wait(long) reads that waiting lasts until:
...
The specified amount of real time has elapsed, more or less.
It does not say neither "at most" nor "at least". I think we can fix both
tests so that they could wait a little bit less than it is now expected and
print the values at error messages. I attached a patch to HARMONY-2204.
Please take a look and commit if it is OK. Then we can see if the tests
still fail.
--
Gregory
