Fix detection of thread-local storage capability for MSVC #31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes an incorrect check for detecting whether MSVC supports thread-local storage or not.
The build system uses the cmake function
try_compile
to compile a test file which containsextern __thread int x
, but this code always fails with MSVC since the correct thread-local attribute would be__declspec(thread)
(Source from Microsoft). The__thread
keyword is redefined for MSVC in cmake for the library, but this does not affect this call totry_compile
.This then leads to the thread-local attribute being omitted for MSVC builds, which in turn leads to crashes when calling into the library from multiple threads at the same time.
I tested this change with the latest MSVC compiler by writing a small test program with calls
METIS_PartGraphRecursive
inside astd::for_each(std::execution::par, ...)
loop. Without this change the code crashes even for just two parallel executions, with the change it runs successfully for a larger number of parallel executions.Since the file
conf/check_thread_storage.c
is only used by the build system when the MSVC compiler is being used, it should be fine to change it like this.A PR with the same fix was also supplied to the METIS repository (METIS/pull/74)