Fix thread unsafety due to internal use of set_var() #84
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 is the first of two patches aimed at addressing thread safety issues. set_debug() and set_pipefail() change the debug and pipefail settings by using std::env::set_var(), which is now known to be unsafe to use in multi-threaded programs. note that the unsafety is not because it has global effect when it works as intended (this will be addressed in the second patch), but rather that it may not work as intended if other threads are reading from the environment.
this patch reworks set_debug() and set_pipefail() to write to a LazyLock<AtomicBool> variable for that setting. these variables read from the environment variables on first use. this is technically a breaking change, because consumers may have relied on changing these settings with std::env::set_var(), but such consumers were incorrect anyway.
i’ve also updated the docs for thread safety issues and global state to improve their accuracy.