Fix static initialization fiasco problem with the logger and code calling into it from other TUs #358
+19
−7
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.
There is currently a dependency between the order of dynamic initializers for the logger and things that call into it, like CpuREP (see #356 for a related issue). This can result in crashes because the order of dynamic initializers across translation units is not deterministic in C++.
The fix is to access the logger via a function call that allows us to defer the logger initialization until it is needed (in a thread-safe manner). Using "magic statics" to do that.
An app will now be able to customize the log level (to suppress logging from dynamic initializers) by exporting a function with a certain name, which we will look up during
GetLogger()
:App code:
Fixes #356