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.
I checked the APR function and underlying win API functions, the
System.currentTimeMillis is measured with microseconds accuracy. The
Thread.join and Thread.wait end up with WaitForSingleObject function
which accepts an argument in milliseconds. So I cannot understand why
the wait/join time is less than required.
--
Gregory
