Closed JohnStarich closed 1 month ago
For further details, here's some snapshots of the data races I can produce with the first commit 83abad0:
Hi @JohnStarich , thank you for the contribution, this looks good. I will take a deeper look at this next week.
Filed internally as 244791.
Hi @JohnStarich , I've merged this PR into a feature branch prior to merging to the main branch.
I made an additional set of changes here: https://github.com/launchdarkly/go-server-sdk/pull/152.
Please review when able.
Thanks for taking a look! Reviewed!
This has been released in https://github.com/launchdarkly/go-server-sdk/releases/tag/v7.4.1. Please file another issue if you have any other problems. Thanks!
Requirements
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 https://github.com/launchdarkly/go-server-sdk/issues/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 onb.subscribers
Close()
had a data race where closing a send channel triggers a panic inBroadcast()
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 preventBroadcast()
ing on a full send channel from blockingClose()
.Additional context
Add any other context about the pull request here.