Elena Semukhina wrote:
On 11/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
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.
I'm not an author of the test but I think we should wait one more
millisecond even if we ask to wait 500.0005 ms because a millisecond is a
minimal available time unit. I expect that the time is rounded up rather
than towards the nearest vlaue. Am I wrong?
Well it appears that on windows assertion in the test fails once in a
while. The time of waiting finish - start + 1 = 500, so it is not
strictly greater than millis = 500.
I didn't try to run the test multiple times after your patch to APR.
I'll let you know if I get the failures again.
--
Gregory
