From harmony-dev-return-19149-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Nov 16 15:24:41 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 34351 invoked from network); 16 Nov 2006 15:24:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Nov 2006 15:24:40 -0000 Received: (qmail 76805 invoked by uid 500); 16 Nov 2006 15:24:48 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 76769 invoked by uid 500); 16 Nov 2006 15:24:48 -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 76760 invoked by uid 99); 16 Nov 2006 15:24:48 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Nov 2006 07:24:48 -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; Thu, 16 Nov 2006 07:24:34 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gkj5Z-0002tR-Ft for harmony-dev@incubator.apache.org; Thu, 16 Nov 2006 16:23:41 +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 ; Thu, 16 Nov 2006 16:23:41 +0100 Received: from gshimansky by msfwpr01.ims.intel.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 16:23:41 +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: Thu, 16 Nov 2006 18:23:15 +0300 Lines: 36 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: > 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