coder / coder/websocket

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

Đang mở
#573 2 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Go
Star
5.5k
Fork
372
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

Hi, I was looking at [mu.lock](https://github.com/coder/websocket/blob/master/conn.go#L286) and had a question about this part:

```go
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?

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Hướng nghiên cứu

Bắt đầu với conn.go, quanh mu.lock ở dòng 286, và theo dõi cách context của nó cùng các channel đã đóng được các caller sử dụng. So sánh hành vi hủy và thu nhận lock, sau đó xác định liệu trường hợp được báo cáo có yêu cầu thay đổi code hay tài liệu hay không; hoàn tất nghĩa là câu hỏi của issue đã được trả lời bằng một lập luận có thể tái hiện.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
go
Lĩnh vực
networking
Loại issue
Lỗi
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Sôi nổi
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
42/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.