A goroutine parked in sync.Cond.Wait ignores context cancellation — how do you make shutdown work?

## The problem, stated precisely `sync.Cond`'s entire waiting API is `func (c *sync.Cond) Wait()`. There is no variant taking a `context.Context`, no variant taking a deadline, and no channel you could put in a `select`. A goroutine inside `Wait` is parked on the condition's internal notify list, and the *only* events that move it are `Signal` and `Broadcast` on that same `*sync.Cond`. That has a blunt consequence for anyone maintaining a package written before `context` existed: cancelling the context you passed in does nothing to a goroutine already parked. `ctx.Done()` closes, `ctx.Err()` becomes non-nil, and the waiter sleeps on regardless. In a graceful shutdown that tries to drain workers and join them, the join hangs; in a goroutine dump you see the stuck goroutines sitting in `sync.(*Cond).Wait` with an ever-growing wait duration. ## Remedy 1 — make cancellation part of the predicate This is the idiomatic fix, and it is the one to lead with. A condition variable is only ever a notification about lock-protected state, so express cancellation *as* lock-protected state: 1. Add a field — `closed bool`, or better an `err error` recording why — guarded by the same mutex as the rest of the state. 2. Every waiter's loop condition includes it: `for len(q.items) == 0 && !q.closed`. 3. After the loop, distinguish the two exits: real work available, or shut down (return an error). 4. Shutdown takes the lock, sets the flag, unlocks, and calls `Broadcast` — not `Signal`, because the flag concerns every parked goroutine. This turns "cancel" into an ordinary state transition that the existing machinery already handles correctly, and it needs no new primitive. ## Remedy 2 — bridge a context into that flag When the caller already hands you a `context.Context` and expects it to be honoured, connect the two explicitly. Since Go 1.21 `context.AfterFunc(ctx, f)` runs `f` in its own goroutine as soon as `ctx` is done, and returns a `stop` function you call to detach it when you no longer need it: ``` stop := context.AfterFunc(ctx, func() { q.mu.Lock() q.closed = true q.mu.Unlock() q.notEmpty.Broadcast() }) defer stop() ``` The bridge goroutine is the thing that watches the context; the condition variable still only ever responds to `Broadcast`. Call `stop()` on the normal path so the watcher does not outlive the work — and note that this cancels *everyone* waiting on that `Cond`, which is right for a shared resource being shut down but wrong if you wanted a per-caller deadline. ## Remedy 3 — per-caller deadlines mean the wrong primitive If what you actually need is "this one caller gives up after 200ms while the others keep waiting", `sync.Cond` cannot express it, and no amount of flag-setting will make it. That requirement is a channel requirement: hand each caller something it can `select` on alongside `ctx.Done()`. Rewriting a small internal queue that way is usually a day's work and removes a whole class of shutdown bugs. The honest interview answer names this as the real endpoint rather than layering tricks on the condition variable. Anti-patterns worth naming so you can reject them: a background goroutine that `Broadcast`s on a ticker so waiters "periodically get a chance to notice" — that turns a precise wake-up into polling and still gives no deadline guarantee; and relying on process exit, which does release the goroutines but only by killing everything, so any in-flight work and any deferred cleanup in those goroutines is lost. ## Proving it, and diagnosing it The behaviour is testable without any timing luck. Start N waiters, each incrementing a parked counter under the mutex before calling `Wait`; spin until the counter reaches N so you know all N are actually parked; then cancel the context (or call `Close`) and require all N to return. Run the same harness with `Signal` instead of `Broadcast` and watch exactly one return — the difference is then a fact your test suite enforces rather than a comment. In production the diagnostic is the goroutine profile. Waiters blocked here appear with `sync.(*Cond).Wait` in their stack, and because a parked goroutine keeps alive everything its frame references, a leaked set of them is visible both as a rising goroutine count and as retained memory. A goroutine count that never returns to baseline after a shutdown request is the tell that some `Cond` never got its `Broadcast`. ## The reviewer's checklist When this shape reaches a code review, three questions catch nearly everything: is there any state change at all that can make the wait loop exit besides the happy path; is the shutdown notification a `Broadcast` rather than a `Signal`; and does every waiter distinguish "woke up with work" from "woke up because we are shutting down" instead of falling through as if it had work.