Martin Wille <mw8329@yahoo.com.au> writes:
Anthony Williams wrote:
Martin Wille <mw8329@yahoo.com.au> writes:
John Maddock wrote:
Anyone any ideas about the remaining thread library regressions: http://beta.boost.org/development/tests/trunk/developer/issues_release_.html... they're causing Boost.Regex failures as well apart from anything else :-( That one is twofold. There's an error due to a resource limit (which I can lift). There's a second error described in http://svn.boost.org/trac/boost/ticket/1323
The assertion failure is not a bug in the thread library. It is a bug in the way the test is run: when the resource limit failure is thrown, a condition variable is destroyed whilst there are still threads waiting on it.
I am not sure which aspect of the test-running is causing that problem.
The tests simply are run with a limit on RLIMIT_NPROC.
If that limits the number of threads, some of my tests will break. The shared_mutex test spawns 100 threads in order to stress-test it, for example.
Or are you referring to the code of the test itself?
I'm referring to the code of the executable test rather than the test environment. In the barrier test, for example, if the test can't launch enough threads, the already-launched threads will be waiting on the barrier. The test thread will then abort, destroying the barrier, whilst still having threads waiting. This is a bug in the test: the existing threads should be interrupted and joined under such circumstances. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL