Boost Test thread safety
Hi folks: I'm trying to identify whether or not the boost Test library is thread safe in the sense that multiple threads can simultaneously interact with the library's various macros and API. I'm more interested in a single test being multi-threaded than being able to run multiple test cases simultaneously. In early documentation of the Test library (version 1.58.0 and before) , there's a section in the introduction called "Open issues" that indicates that the library is not thread-safe. However, the documentation after 1.58.0 was substantially re-written, and I don't see any discussion regarding thread safety at all. The question remains. is the Test library thread-safe or not? If there is a definitive statement regarding this issue, please let me know. Thanks in advance!
On 19.11.18 16:25, Dan Field via Boost-users wrote:
Hi folks:
I’m trying to identify whether or not the boost Test library is thread safe in the sense that multiple threads can simultaneously interact with the library’s various macros and API. I’m more interested in a single test being multi-threaded than being able to run multiple test cases simultaneously.
In early documentation of the Test library (version 1.58.0 and before) , there’s a section in the introduction called “Open issues” that indicates that the library is /not/ thread-safe. However, the documentation after 1.58.0 was substantially re-written, and I don’t see any discussion regarding thread safety at all.
The question remains… is the Test library thread-safe or not? If there is a definitive statement regarding this issue, please let me know.
Thanks in advance!
As of today, virtually nothing has been done to make the library thread safe. It is not impossible but it would require quite a chunk of work. Raffi
On Wed, 20 Feb 2019 at 23:59, Raffi Enficiaud via Boost-users
As of today, virtually nothing has been done to make the library thread safe. It is not impossible but it would require quite a chunk of work.
Raffi
As a user data point: Both in the company I work for and in some other projects I work on, I had to resort to use GTest instead of either Boost.Test or Catch2 because of the lack of thread-safe checking api. Apparently Catch2 author now plan to implement thread-safe assertions. Just so you know that it's an important feature for a lot of projects (but I understand it's not necessarilly easy to provide). A. Joël Lamotte
On 21.02.19 02:15, Klaim - Joël Lamotte via Boost-users wrote:
On Wed, 20 Feb 2019 at 23:59, Raffi Enficiaud via Boost-users
wrote: As of today, virtually nothing has been done to make the library thread safe. It is not impossible but it would require quite a chunk of work.
Raffi
As a user data point: Both in the company I work for and in some other projects I work on, I had to resort to use GTest instead of either Boost.Test or Catch2 because of the lack of thread-safe checking api. Apparently Catch2 author now plan to implement thread-safe assertions.
Just so you know that it's an important feature for a lot of projects (but I understand it's not necessarilly easy to provide).
A. Joël Lamotte
Thanks for the feedback. I know it is an important feature, and it is there for a long time :) (see eg. https://svn.boost.org/trac10/ticket/3484). What would be possible at low/moderate cost would be to have thread safety while inside a test case, where assertions and messages can come from different threads. Would that make you use boost.test? In a second step, I can work on making the framework thread-safe such that we can enable parallel test-case execution. This would be more tricky because it involves more components. I suggest we start easy. Raffi
participants (3)
-
Dan Field
-
Klaim - Joël Lamotte
-
Raffi Enficiaud