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.
Fix send-on-closed-channel panic in
blockSubscriber
Motivation:
I caught this bug while stress-testing RSocket-based Client/Server implementation in Facebook Thrift: https://github.com/facebook/fbthrift/blob/main/thrift/lib/go/thrift/stress/server_test.go
This bug is caused by a potential race condition on the following lines:
rsocket-go/rx/mono/block_subscriber.go
Lines 41 to 43 in 099cb5b
done
channel gets closed, andechan
gets sent on.done
channel closing. However, it may run to completion beforeechan
is sent on. If that happens - the receiver will closeechan
and the sender (blockSubscriber
) will send on a closed channel - panic!rsocket-go/rx/mono/utils.go
Lines 170 to 182 in 099cb5b
Modifications:
blockSubscriber
the explicit owner of all the channels (done
/vchan
/echan
).done
channel can be closed only once - by protecting it with anatomic.Bool
that gets swapped totrue
afterdone
is closed.vchan
/echan
don't actually need to be closed (there is no such requirement in Go - the channels will just be garbage collected).Result:
With this change - I was not able to reproduce this failure/panic anymore.