Senior · Concurrency
Select, timers and fairness
Does select always prefer cancellation over a ready result?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
When multiple cases can proceed, select chooses one pseudo-randomly. Source order does not prioritize cancellation. A default case makes the select nonblocking and can create a hot spin loop.
Deadlines require timers or context, not repeated sleep polling. Timer channel behavior changed in recent Go versions, so check the target toolchain and package contract instead of repeating an obsolete stop/drain recipe.
Specify acceptable semantics when cancellation and a result become ready together. If an API must never commit after cancellation, a select alone cannot provide a distributed transaction boundary.
Common trap
Adding ctx.Done as the first case does not turn it into a strict priority queue.
Try it
A worker sees both ctx.Done and a buffered job ready. Can it take the job?
Worked solution
Yes. Guard expensive work with an additional cancellation check if avoiding unnecessary work matters, but describe remaining races honestly. Enforce irreversible operation semantics in the authoritative protocol.
Change the constraint
Why can a select with a default case consume a full CPU while doing no useful work?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.