Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: STDCXX-536
Date: Fri, 14 Mar 2008 10:17:34 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A364E@exchmail01.Blue.Roguewave.Com>
Thread-Topic: STDCXX-536
Thread-Index: AciCP0v/LJ97I3AMQ4ONFVj+jJbMmQDr1U/g
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3632@exchmail01.Blue.Roguewave.Com>
 <47D47592.2090005@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>


FWIW, I just noticed that mpfr <http://www.mpfr.org/> contains the
following configuration option:

  --enable-tests-timeout=3DNUM    enable timeout (NUM seconds) for test
programs
                          (NUM <=3D 9999) [default=3Dno]; if enabled, =
env
variable
                          $MPFR_TESTS_TIMEOUT overrides NUM (0: no
timeout).

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
>=20
> Eric Lemings wrote:
> > FWIW, I was just reading the description for Jira issue=20
> STDCXX-536 and
> > the associated comments.
> > =20
> > I believe this is basically what Travis has already stated=20
> in a round-
> > about manner but it seems to me that if a test is timing=20
> 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=20
> 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=20
> a reasonably
> > short amount of time -- a couple of minutes at most on the slowest
> > supported platforms.
>=20
> 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.
>=20
> 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.
>=20
> >=20
> > And aren't multithreaded programs (or tests) supposed to=20
> perform faster
> > -- not slower -- than their single-threaded counterparts?  :)
>=20
> Only if they are written to avoid contention, which is the exact
> opposite of what our thread safety tests are designed to do.
>=20
> Martin
>=20