Fix panic in multiListener #329
Conversation
If Close() is called concurrently, both goroutines could pass the select’s default case before either of them executes close(), resulting in the channel being closed twice
The committers listed above are authorized under a signed CLA. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: denpeshkov The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Welcome @denpeshkov! |
| @@ -169,12 +168,6 @@ func (ml *multiListener) Close() error { | |||
| ml.wg.Wait() | |||
| close(ml.connCh) | |||
|
|
|||
| // Drain any already-queued connections. | |||
There was a problem hiding this comment.
dropping this doesn't look related to fixing the concurrent Close() race... why was this code removed?
| func(ctx context.Context, network, address string) (net.Listener, error) { | ||
| return lc.Listen(ctx, network, address) | ||
| }) | ||
| lc.Listen, |
There was a problem hiding this comment.
this looks unrelated to the Close() race fix
If
Close()is called concurrently, both goroutines could pass theselect’s default case before either of them executesclose(ml.stopCh), resulting in the channel being closed twice/kind bug