Re: [boost] Re: boost.test thread safe bugs (and some fixes)

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-17 05:31:54

Gennadiy Rozental said:
>> I've been looking at your signal handling implementation in
>>execution_monitor.cpp, and I think I've uncovered quite a few bugs,
>> some of which are really quite fatal for multithreading code.
>
> The code never promised to work in multithreaded environment, nor even
> to be thread save. It is in my to-do list. Though recent hands in
> several situations may require address some of these issues sooner.

What?!?  Where's the big, bold disclaimer about that! We have to have all
of the Boost.Test library thread safe, because the Boost.Thread library
depends on it.

>>Issue 1:
>>~~~~~
>>You use a singleton for the signal handling jump:
>>
>>inline sigjmp_buf & execution_monitor_jump_buffer()
>>{
>>    static sigjmp_buf unit_test_jump_buffer_;
>>    return unit_test_jump_buffer_;
>>}
>>
>>There are two issues with this:
>>
>>a) It is not reentrant: if the monitored procedure called by
>> catch_signals calls another monitored procedure then the inner
>> catch_signals call will overwrite the jump data for the outer call.
>> IMO this situation is quite common - and actually occurs in your own
>> unit test code I believe.
>
> No. I don't think it's common situation. You don't usually create and
> run test cases inside the other test case code.

*I* had considered doing just this, in order to get a tree structure for
dependent test cases.  Nothing in the documentation seems to indicate this
is something that's not supported, and I think that would be the wrong
answer in any event.

>>To make this thread safe you would need to store the pointer in a
>> thread local storage slot, BTW I don't think you can use boost.threads
>> for this,
> as
>>it will create a dependency quagmire for status/Jamfile :-(
>
> I thought to introduce macro BOOST_MULTITHREADED_UNIT_TEST and guard all
> usage of Boost.Thread with it. It does not create extra dependency and
> should allow to build multithreaded version with bjam subvariant
> feature.

How would this work for the Boost.Thread library.  Boost.Test must be
usable by Boost.Thread, and this means it must be thread safe with out
using Boost.Thread.

>>The difficulty we have now is that there is a release coming up, and
>> boost.test is pretty mission critical for that, and these aren't really
>> trivial issues to fix, I'm not sure how we should handle that - ideas?
>
> I was aware of thread safety issues. And still I don't think it is so
> critical, that we need to hurry to fix it for this release. My plan was
> to address it after CLA. I still hope to be able to use Boost.Thread for
> this. I will try to address 1(without tss) 2 and 4 today.

Thread safety issues are very critical, AFAICT.  Boost.Threads depends on
Boost.Test, and assumes it is thread safe.

-- 
William E. Kempf