-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Race condition #4105
Comments
Duplicate of #3992 |
Thanks. I'm actually using a small subset of go-ipfs, and this is the only race that is triggered for me (unlike when running the full daemon). |
See race condition reported at ipfs/kubo#4105 Reuse `whlock` for `whandshake`
This is actually an intentional, benign race to avoid atomic operations on the fast path. I wonder if there's some way to tell go that. Basically, this check can fail at most once per goroutine. If the check fails, we'll take the lock, perform the non-racy check, then record that the check has actually succeeded. |
@Stebalien maybe we should just do an atomic operation to make go happier? |
Probably. Conversation continued on this PR: multiformats/go-multistream#17 |
This was fixed in multiformats/go-multistream#21 (afait, anyway fixed)
I know the value to answer to 2017 comment is extremely low but anyway. |
I building on top of go-ipfs and I have a race condition in my program. It turns out the race is part of the go-ipfs dependency, and can easily be triggered with
make test_go_race
on my system (MacOS X). I am trying to get my programs race-free so any help fixing it would be greatly appreciated.Below is the race report.
The text was updated successfully, but these errors were encountered: