mu.lock: after acquiring m.ch, why does the re-check only look at closed and not ctx?

未关闭
#573 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
42/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
go
领域
networking

调研方向

从 conn.go 第 286 行附近的 mu.lock 开始，追踪其 context 和已关闭 channel 是如何被调用方使用的。比较取消和获取 lock 的行为，然后确定报告的情况是否需要修改代码或文档；完成的标准是通过可复现的依据回答 issue 的问题。

由索引模型根据 Issue 内容生成。

描述

Hi, I was looking at mu.lock and had a question about this part:

func (m *mu) lock(ctx context.Context) error {
	select {
	case <-m.c.closed:
		return net.ErrClosed
	case <-ctx.Done():
		return fmt.Errorf("failed to acquire lock: %w", ctx.Err())
	case m.ch <- struct{}{}:
		// To make sure the connection is certainly alive.
		// As it's possible the send on m.ch was selected
		// over the receive on closed.
		select {
		case <-m.c.closed:
			// Make sure to release.
			m.unlock()
			return net.ErrClosed
		default:
		}
		return nil
	}
}

After acquiring the lock, closed is checked again in case both branches were ready.

Why isn't ctx.Done() checked here as well?

Could ctx be canceled right after m.ch is selected, causing lock to return nil while holding the lock with an already-canceled context?

主要语言
Go
星标
5.5k
派生
377
30 天内没有已合并 PR

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

coder/websocket 的其他 Issue

查看 coder/websocket 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。