Elena, As far as I understand from your letter the implementation is still to be fixed. Could you please file a JIRA about it?
Geir, As for the best of my knowledge there are no reliability runs for kernel tests. This case proves that trying to run these tests in a loop, especially in one JVM could be useful for detecting new implementation flaws. -- Thank you, Alexei On 11/27/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
On 11/28/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: > > The problem with ThreadTest has not been fixed yet. I'm running this test > iteratively now to see the sporadic failures. Indeed, testJoinlongint() > fails rather often. The spec for join() reads that it should wait at most > millis milliseconds for this thread to die. But the thread which is > joining in the test does not stop > The obvious typo: I meant "the thread which is joined". running. Can we allow join() to exit earlier in this case? > I modified the test so that to let join() wait for10 ms less (which is 0.5%of waiting time) and ran it again iteratively. It failed once with 1972 ms of waiting! I looked through RI's bug database for relevant issues and found the following: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368 The last comment of the latter says that the spec will be fixed in Java SE 6.0! BTW, the test always passes on linux for me. Thanks, Elena > On 11/28/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > I may have missed it, it's very possible, could someone point me to the > > fix > > or the thread ? My comments are based on what's in Harmony drlvm trunk > > as of > > a few hours ago. > > > > Thanks, > > Rana > > > > > > On 11/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > > > > I thought this exact problem was identified and already fixed... > > > > > > geir > > > > > > Rana Dasgupta wrote: > > > > Hi, > > > > On Windows XP, java.lang.ThreadTest ( testJoinlongint component ) > > > keeps > > > > failing for me sporadically. Debugging this, I saw that the problem > > was > > > > with > > > > the expiry interval on thread.join(millis, nanos ). Tests based on > > timed > > > > waits are somewhat unpredictable on most platforms. > > > > In condvar_wait_impl(), we seem to set up the timeout interval in > > > > microseconds before calling apr_thread_cond_timeout(). On Windows, > > > > apr_thread_cond_timeout() implements using WaitForSingleObject( > > event, > > > > timeout )....but the Windows timeout is in milliseconds, as far as I > > > > > know. > > > > Is this not an error, or am I missing something? I did not want to > > > change > > > > anything since condvar_wait_impl() is on the code path of several > > timed > > > > waits. > > > > Also, on a less important note, the tests testJoinLong() and > > > > testJoinLongint() seem to test to see that the thread.join(milli, > > nano) > > > > timeout is "at least" equal to the specified interval. My > > understanding > > > is > > > > that this should be "at most" the specified interval. Any ideas? > > > > > > > > Thanks, > > > > Rana > > > > > > > > > > > > > > -- > Thanks, > Elena -- Thanks, Elena
-- Thank you, Alexei
