Open darbyjohnston opened 3 weeks ago
yes, the OPENEXR_ENABLE_THREADING continues to be maintained more for an embedded device scenario. The preferred solution if you are using in a threaded context is to leave it enabled and do as you do and setGlobalThreadCount to 0, or to do something like what I've proposed to switch the default threadpool to tbb in #1852 (we will include that option in the next non-patch release), or to replace the threadpool with your own, which is also now an option...
It would be nice to add a note about the thread safety in the option's comments, it took me awhile to track this down. I can create a small PR for it.
Thanks, that would be awesome, it would be better to be clearer that it disables any use of threading primitives, rendering the library potentially unsafe. A few releases from now, I hope to coalesce and remove some of that static data, perhaps allowing a lock-free type extension system to replace it... thanks in advance for submitting a PR.
I just added a small comment that the library may not be thread-safe when the option is disabled: https://github.com/AcademySoftwareFoundation/openexr/pull/1908
Hi, I have been compiling OpenEXR with the option
OPENEXR_ENABLE_THREADING=OFF
, and have been seeing occasional crashes in the ImfHeader code. My application is already multi-threaded so I thought turning off threads in OpenEXR would be OK. The documentation for the option inOpenEXRSetup.cmake
says:However it looks like the option also removes a mutex in
ImfHeader.cpp
that is protecting some static data:I think without this mutex multiple threads are accessing static data which causes the crash.
I created a small test program that uses
std::async
to open a number of EXR files in multiple threads. WithOPENEXR_ENABLE_THREADING=OFF
it crashes fairly quickly with this trace:This is the test code:
This is with OpenEXR v3.2.4 on macOS 13.7.
For now I can work around the issue by setting
OPENEXR_ENABLE_THREADING=ON
andImf::setGlobalThreadCount(0);
.