Closed JustinDrake closed 1 year ago
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).
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: https://github.com/multiformats/go-multistream/pull/17
This was fixed in https://github.com/multiformats/go-multistream/pull/21 (afait, anyway fixed)
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.
I know the value to answer to 2017 comment is extremely low but anyway.
sync/atomic
is the way to tell go that, on amd64 simple loads and writes compiles to plain old boring memory loads and writes and have no performance costs because amd64's whole memory model is consistent that way 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.