From dev-return-7064-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Mon Mar 17 22:40:04 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 95253 invoked from network); 17 Mar 2008 22:40:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Mar 2008 22:40:04 -0000 Received: (qmail 25285 invoked by uid 500); 17 Mar 2008 22:40:02 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 25221 invoked by uid 500); 17 Mar 2008 22:40:02 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 25212 invoked by uid 99); 17 Mar 2008 22:40:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Mar 2008 15:40:02 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Mar 2008 22:39:23 +0000 Received: from nebula.bco.roguewave.com ([10.70.3.27]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m2HMdXgO012121 for ; Mon, 17 Mar 2008 22:39:33 GMT Message-ID: <47DEF325.9080106@roguewave.com> Date: Mon, 17 Mar 2008 16:39:33 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: STDCXX-536 References: <47D47592.2090005@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Eric Lemings wrote: > FWIW, I just noticed that mpfr contains the > following configuration option: > > --enable-tests-timeout=NUM enable timeout (NUM seconds) for test > programs > (NUM <= 9999) [default=no]; if enabled, env > variable > $MPFR_TESTS_TIMEOUT overrides NUM (0: no > timeout). Right. I thought we could do something similar. Martin > > Brad. > >> -----Original Message----- >> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor >> Sent: Sunday, March 09, 2008 5:41 PM >> To: dev@stdcxx.apache.org >> Subject: Re: STDCXX-536 >> >> Eric Lemings wrote: >>> FWIW, I was just reading the description for Jira issue >> STDCXX-536 and >>> the associated comments. >>> >>> I believe this is basically what Travis has already stated >> in a round- >>> about manner but it seems to me that if a test is timing >> out, there are >>> two possibilities: 1. the test is caught in an infinite loop, or 2.) >>> the test requires too much time to completely execute. In >> either case, >>> the test needs to be rewritten to fix the infinite loop or to break >>> the test into smaller tests that can completely execute in >> a reasonably >>> short amount of time -- a couple of minutes at most on the slowest >>> supported platforms. >> Right, that's the conclusion we came to for the tests that can be >> broken up. The downside of doing this is code duplication (either >> source or object) between the small tests that share the same >> scaffolding, which will increase compilation and/or link times, >> and, of course, run times. With a large enough of number of these >> little tests the consequences could be actually worse than the >> status quo. >> >> The problem with most of our thread safety tests is that they are >> written to do the sane fixed number of operations in parallel, and >> this number takes a different amount of time depending on factors >> such as the scheduler's time slice and the system load. Ideally, >> the tests would take these parameters into consideration and run >> for sufficiently long (but no longer) to exercise the functionality >> with some desired percentage of parallelism/contention. To do that, >> the tests would need to be able to time out. >> >>> And aren't multithreaded programs (or tests) supposed to >> perform faster >>> -- not slower -- than their single-threaded counterparts? :) >> Only if they are written to avoid contention, which is the exact >> opposite of what our thread safety tests are designed to do. >> >> Martin >>