[Boost-users] Re: boost::thread::joincausesassertion(pthreads)

From: Kevin Wheatley (hxpro_at_[hidden])
Date: 2005-03-23 07:22:58

Peter Dimov wrote:
> Vladimir Prus wrote:
> > I interpreted Kevin's post this way -- Boost.Tread fails and does not
> > produce any useful diagnostic.
> 
> The proper way to fix that is to make Boost.Threads not fail, right? That's
> what invariant/"assertion" asserts are for - to catch bugs. They aren't an
> error reporting mechanism.

So,

what I don't know is 100% if the bug is in Boost.Threads, OS,
Compiler, my application, etc, etc.

What I do know is that some of my problem stems from the fact that
Boost.Threads is not just a header only library, it has a library
aspect to it. If everything was perfect in threads then the assertion
does not help me debug my application code (assuming it is in there
that the problem lies) as it discards the platforms' reasons for the
error, it only states that some pre-condition assumed by the code is
broken. 

If threads was header only then I could come up with a macro
controlled mechanism for instance to enable extra output in my
debugging build, this would be different to the Debug and Release
build, but wouldn't require any tinkering with anything other than the
files in question.

For this particular application I'd like 3 states:

release - no asserts, no debugging code, no nothing.
debug - asserts, no debugging code.
debugging - asserts, extra debugging code

(Some people like to leave assertions enabled in release code, some
don't)

currently the built libraries only cover the first 2 cases. Getting
consensus on how to deal with this in general is probably not straight
forward, but maybe threads being what they are (hard to program, easy
to get wrong, not always repeatable) threads could have a special case
need.

Kevin

-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this      |
| Senior Technology                     | My employer for certain |
| And Network Systems Architect         | Not even myself         |