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

From: Martin Pasdzierny (martin_at_[hidden])
Date: 2005-03-23 10:35:56

Hello Thread experts (hi Peter ;-),

I know that keeping concepts well ordered instead of headless hacking is an important virtue.

But I think an "error reporting mechanism" is nothing else but ONE tool to "catch bugs" ?

In my case the boost::thread-asserts occured about 2-7 days after starting the program with ca. 50 threads.
They occured only in productive environments with real loads.
I spent some days to write separate programs reproducing the behaviour with minimized code: no success.
ANY hint would have been helpful as a starting point to find out the bug causing the asserts.
In this situations theoretic discussions are not really welcome ...

One certain bug caused somebody to start this discussion.
Finally it will be not of interest wether it was a bug in his code or inside boost::thread or inside the OS code.

I think it would be a good idea to allow the application programmers to choose the error/assertion policy.

Thanks in advance.

Martin.

Kevin Wheatley wrote:
> 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
> 

-- 
Martin Pasdzierny, <martin_at_[hidden]>