fix handle spurious wakeup wrongly returning Flush too early #340
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.
add an atomic bool to check if flush has actually happened and condition variable did not spuriously wakeup.
fixes #339
2 important changes that fix this behavior hard-to-debug race condition:
mutex
should still be locked when callingnotify
, the problem is lifetime:mutex
is unlocked, the condition variable might get destructed after the destruction of themutex
, by moving it in scope, the lambda is fully destructed before the consumer side kicks in. The consumer holds themutex
that's why themutex
is in scope when the condition variable goes out of scopestd::__1::system_error: mutex lock failed: Invalid argument
Note:
clang
/ on mac, I haven't checked if clang on Linux would show the same thing, likely yes