GULLogger: ignore a data race #1959
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Objective-C does not provide any stronger guarantee. While this is undefined behavior, on the platforms we support this does have predictable behavior, even if that behavior results in uncertainty about the value for some length of time (basically until the next memory barrier). |
|
@wilhuff Thanks for the clarification! |
paulb777
approved these changes
Oct 17, 2018
ryanwilson
approved these changes
Oct 17, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Thread sanitizer spots a data race in
GULSetLoggerLevel(full error message here). This prevents a clean run of Firestore integration tests under TSan.Following #1390, I'm simply making sanitizer ignore this function. However, note that in both C++ and C, a data race is undefined behavior (the compiler is free to produce code assuming the memory in question is never accessed from more than one thread). I don't know if Objective-C provides any stronger guarantees.