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
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
