Open mwpowellhtx opened 7 years ago
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.
Exactly! Before Catch2, and thus C++11, we didn't have std::thread
Sweet, we are all in agreement 👍
@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.
How is that looking? Just ran into this issue, too.
I would love to see this addressed in Catch2.
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
cout
to 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!
Hi all. I also encountered the problem of calling checks from different threads. Are there any progress in this direction?
My +1: I'm also running into issues where I want to test my multi-threaded library, but I have to put in extra effort to make it work with Catch2.
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.