From harmony-dev-return-19285-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Fri Nov 17 14:55:51 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 52013 invoked from network); 17 Nov 2006 14:55:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Nov 2006 14:55:50 -0000 Received: (qmail 70839 invoked by uid 500); 17 Nov 2006 14:55:57 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 70800 invoked by uid 500); 17 Nov 2006 14:55:56 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 70786 invoked by uid 99); 17 Nov 2006 14:55:56 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Nov 2006 06:55:56 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Nov 2006 06:55:43 -0800 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gl57O-0005hc-Ca for harmony-dev@incubator.apache.org; Fri, 17 Nov 2006 15:55:02 +0100 Received: from msfwpr01.ims.intel.com ([62.118.80.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 15:55:02 +0100 Received: from gshimansky by msfwpr01.ims.intel.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 15:55:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: harmony-dev@incubator.apache.org From: Gregory Shimansky Subject: Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass Date: Fri, 17 Nov 2006 17:53:38 +0300 Lines: 61 Message-ID: References: <2A786EB15713B544AB79607529273B04062C32@mssmsx411> <200611132228.51128.gshimansky@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: msfwpr01.ims.intel.com User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) In-Reply-To: Sender: news X-Virus-Checked: Checked by ClamAV on apache.org Elena Semukhina wrote: > On 11/16/06, Gregory Shimansky 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