stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <>
Subject RE: STDCXX-536
Date Fri, 14 Mar 2008 16:17:34 GMT

FWIW, I just noticed that mpfr <> contains the
following configuration option:

  --enable-tests-timeout=NUM    enable timeout (NUM seconds) for test
                          (NUM <= 9999) [default=no]; if enabled, env
                          $MPFR_TESTS_TIMEOUT overrides NUM (0: no


> -----Original Message-----
> From: Martin Sebor [] On Behalf Of Martin Sebor
> Sent: Sunday, March 09, 2008 5:41 PM
> To:
> 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

View raw message