Regression due to Large output redirect refactor

[dthaler]

Describe the bug
Large output redirect refactor rewrote catch_output_redirect.hpp and introduced the following regression that is breaking other repositories that use catch2.

https://github.com/microsoft/ebpf-for-windows/actions/runs/10746638325/job/29808074945 is an example of a github run where nothing changed except the dependabot-generated update of catch2. The tests previously passed and started failing with this update.

The gist is that the test runs two threads concurrently, both of which are using catch2, resulting in

Assertion failed: !m_redirectActive && "redirect is already active"

Expected behavior
Tests should pass without regressions.

Reproduction steps
Steps to reproduce the bug. Take the microsoft/ebpf-for-windows repository.
Verify that the tests pass before the upgrade using .\netebpfext_unit.exe sock_addr_invoke_concurrent1 -d yes.
Upgrade catch2 to latest.
Notice that catch2 hits internal assertions when running .\netebpfext_unit.exe sock_addr_invoke_concurrent1 -d yes

Platform information:
Windows

[shpalani]

Can you provide an estimated time for the regression fix?

[horenmar]

The gist is that the test runs two threads concurrently, both of which are using catch2, resulting in

Do not touch Catch2 from multiple execution threads

[gillesdegottex]

So Catch2 cannot be used to test if a function is thread safe by running it multiple times in parallel?
(I know such a test is not complete, but sometimes that's the only think we can do).

What's the argument behind this design limitation?

EDIT:
I worked around it with a macro:

std::mutex g_catch2_extra_mutex;
#define REQUIRE_TS(expr) {std::lock_guard<std::mutex> guard(g_catch2_extra_mutex); REQUIRE(expr);}