Add additional locking in DemandBuffer to protect demandState #90
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.
I've recently been building a feature where I'm setting up a publisher using
Publishers.Createon the main thread, and then sending values to the generated subscriber from another thread (this might an unsupported use-case for this publisher, let me know if so!). When debugging the code with Thread Sanitizer I get a warning about an access race:Looking at the code I can see that a
NSRecursiveLockis used to protect thedemandStateinside of the DemandBuffer, but only in theflush()function. Since thedemandStateproperty is also accessed from within thebuffer(value:)function my hunch is that this too should be protected by the lock. The use of the lock here leads me to believe that my threading case might be valid, but again let me know if this isn't the case.This PR adds locking to the
buffer(value:)function. Tests all seem to pass, and Thread Sanitizer is no longer upset with my code 👍🏻