Catch2
Catch2 copied to clipboard
catchorg
Support thread safety throughout the API
I am using INFO, for example, to help record where tests are during execution. This is during a multi-threaded situation: server running in a separate thread. Clients connecting on the parent thread. When I sprinkle INFO throughout client and server code, the program crashes hard.
Just ran into the same issue today as well but with REQUIRE, having support for thread safety in the assertion & logging macros would be really nice. For us it wouldn't have to be for all tests but some of our tests are specifically there to verify multithreaded code
@repi I'm sure it's for REQUIRE as well. I just called out INFO as a first observation. Point is, thread-safety is A MUST.
This need is one of the key drivers for Catch2 rebasing on C++11. Once Catch2 is fully released this will be one of the first major tasks - it's been on the wish-list for a looong time.
@philsquared I'd say with the advent of std::thread, there really is no excuse for it to be a wish. In other words, that's not strong enough of a word, IMO.
@repi @philsquared Yes, I think we agree on the what. Now is a question of the when, which may necessarily be predicated on the who.
No idea; I've moved on to other non-C++ areas at the moment, so this is not on my radar screen apart from peripheral view.
Looks like this is still an issue - I have some places where I try to call UNSCOPED_INFO from a non-test thread and Catch2 blows up. It's a real bummer because detailed logs can be a huge help when trying to debug test failures.
Has anyone come up with a decent workaround? I've resorted to changing my logging to output via straight cout to help with debugging.
Has anyone come up with a decent workaround? I've resorted to changing my logging to output via straight
coutto help with debugging.
Perhaps a producer-consume queue where log messages are queued from your worker threads and then passed on to UNSCOPED_INFO in the main thread while it waits for your worker threads to finish?
That's a reasonable suggestion! Though it does introduce a little boilerplate into my test methods - it's better than my current situation.
I do hope native support for this arrives in Catch2 eventually. :)
My workaround was to create a global mutex and then have wrapper macros that lock that mutex, call the catch macro, and the unlock the mutex.
My workaround was to create a global mutex and then have wrapper macros that lock that mutex, call the catch macro, and the unlock the mutex.
Mutexes are probably a more reasonable approach than a producer-consumer queue. I was thinking of an asynchronous logger when I had suggested that.
TBH, a pub/sub pattern is going to guard its boundaries anyway. Probably internally, i.e. with a mutex.
TBH, a pub/sub pattern is going to guard its boundaries anyway. Probably internally, i.e. with a mutex.
True, but directly using a mutex involves a lot less code than an entire producer-consumer queue that uses a mutex internally.
Yes of course. The runtime and the scaffold being what it is. Of course, I am an OO guy, and I like the abstraction. From the consumer perspective, which is what any of us would be 99.9% of the time, don't have to think about the moving parts.
Any status updates on this? I just bumped into it after running helgrind on a test suite that uses catch2.
@horenmar @philsquared and other. Any updates on this?
The documentation about Catch2 limitation states (https://github.com/catchorg/Catch2/blob/devel/docs/limitations.md#thread-safe-assertions):
Because C++11 provides the necessary tools to do this, we are planning to remove this limitation in the future.
What is the plan for this? C++11 is around 11 years now.
C++11 is around 11 years now.
I'm not sure what you are trying to achieve with this quip. I suspect that the maintainers are perfectly aware of the year C+11 was released, and that the delay is because of a shortage of available maintainer time, rather than language maturity. 😉
I just hit the same limitation while tracking down thread sanitizer issues in the unit tests of our library (alpaka). We are basically calling CHECK(...) from two different threads. After a brief look into the code of Catch2 (where TSAN pointed me), it seems making just the assertion macros work could be a matter of just adding a mutex and a lock around the critical part. That would already be a big help!
