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 running. Can we allow join() to exit earlier in this case?
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
