-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data race in internal/broadcasters.go #102
Comments
Hi @dlamotte, thank you for the report. I'll investigate. |
Can you post your SDK configuration? |
@cwaldren-ld I think you want this?
It's a partial. Hopefully its enough. |
cwaldren-ld
pushed a commit
that referenced
this issue
May 28, 2024
**Requirements** - [x] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/v5/CONTRIBUTING.md#submitting-pull-requests) - [ ] I have validated my changes against all supported platform versions * What does "platform" mean here? Go version? OS version? Happy to help test, just not sure what I'm testing! **Related issues** I hit data races when running tests in parallel, which effectively obscures other data races my application may have. It looks like others did too, judging by #102. Fixes #102 **Describe the solution you've provided** I've addressed 2 data races with improved locking: * `HasListeners()` had a data race due to any mutation on `b.subscribers` * `Close()` had a data race where closing a send channel triggers a panic in `Broadcast()` I also saw an easy opportunity to use more fine-grained locks with an RWMutex, although I'm happy to back that out if you would prefer. **Describe alternatives you've considered** I also considered using an atomic data type for subscribers, but I figured that change would be less of a surgical fix. It also may be more difficult to mutate the slice, since a compare-and-swap can fail and would need a loop (it's not as simple as `atomic.Add`). Another idea which may be simpler is using a channel to manage shutdown. Typically I'd use a `context.Context` here to manage cancellation. That'd also prevent `Broadcast()`ing on a full send channel from blocking `Close()`. **Additional context** Add any other context about the pull request here.
Appears fixed by #151 (looks like there is another follow-on PR, but best follow those PRs) |
This has been released as part of https://github.com/launchdarkly/go-server-sdk/releases/tag/v7.4.1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this a support request?
No.
Describe the bug
https://github.com/launchdarkly/go-server-sdk/blob/v7/internal/broadcasters.go#L70 accesses
b.subscribers
without guarding the access with a mutex.To reproduce
go test -race
You might need-count=100
. Our units running with-race -count=100
routinely fail here.Expected behavior
No data races.
Logs
...
redacted aspects of our codebase as they are not important.SDK version
Language version, developer tools
go version go1.21.4 darwin/arm64
OS/platform
OSX.
Additional context
Impact is that we cannot use
-race
when running our unit tests to find races. So we have to have two unit test runs until this is fixed which is not ideal as we actually had a data race in our code on top of this code. So, I'd prefer to eliminate this race so we can ensure we don't have races in our code.The text was updated successfully, but these errors were encountered: