mu.lock: after acquiring m.ch, why does the re-check only look at closed and not ctx?
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- go
- Domain
- networking
Research direction
Start with conn.go around mu.lock at line 286 and trace how its context and closed channels are used by callers. Compare the cancellation and lock-acquisition behavior, then determine whether the reported case requires a code or documentation change; done means the issue's question is answered with a reproducible rationale.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- Go
- Stars
- 5.5k
- Forks
- 377
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coder/websocket
-
Must not wrap io.EOF Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
export wstest Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
NVIDIA/gpu-operator#2955 ·
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
kovidgoyal/kitty#10516 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
cisagov/vulnrichment#337 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100