select and Non-Blocking Communication

A worker collects results from a channel, but the caller may cancel at any moment. Before select, this forces an ugly choice: block on <-results and the worker cannot notice cancellation; poll the cancel flag on a timer and you trade latency for wakeups; spawn one extra goroutine just to forward signals and now you manage its lifetime too. select resolves the deadlock directly: it waits on several channel operations at once and runs the first one that can proceed.

func work(jobs <-chan Job, results chan<- Result, done <-chan struct{}) {
	for {
		select {
		case j, ok := <-jobs:
			if !ok {
				return // jobs channel closed: stream over
			}
			results <- run(j)
		case <-done:
			return // caller cancelled: stop now
		}
	}
}

Read the mechanics precisely, because every select rule hangs off this shape:

• Uniform readiness. The runtime evaluates all channel cases. If exactly one can proceed, it runs. If several can proceed, one is chosen uniformly at random — not first-in-source-order. Randomness prevents starvation when a fast channel would otherwise always win over a slow one in a long-running loop.
• Blocking when nothing is ready. With no default branch, select parks until any case becomes ready. The goroutine consumes no CPU while waiting — same as a plain receive.
• The send cases are symmetric. case results <- r: participates like a receive; it is ready when a receiver is waiting or the buffer has room. This lets a goroutine wait until either the consumer takes its result or the caller cancels.
• No case, no default: hang. If the select's cases can never become ready — a closed-nil combination, a channel nobody will touch — the goroutine blocks forever, the silent bug class covered in Goroutine Leaks.

A select with a single case behaves exactly like the bare channel operation; the construct earns its keep at two or more cases. And an important composition detail: the results <- run(j) send in the body, outside the select, still blocks without watching done. Production versions pull that send into its own select — one select waiting to send results or to observe cancellation — because a worker blocked pushing into a full result buffer would otherwise ignore the shutdown signal it just received.

Sometimes you do not want to block at all. Is the queue empty right now? Try to push this without stalling the caller? Add a default branch and select stops being a waiting construct and becomes a poll:

func trySend(ch chan<- Job, j Job) bool {
	select {
	case ch <- j:
		return true
	default:
		return false // nobody was ready; caller decides what to do
	}
}

func tryRecv(ch <-chan Job) (Job, bool) {
	select {
	case j := <-ch:
		return j, true
	default:
		return Job{}, false
	}
}

The rule: default runs only when no case is ready at the instant select is evaluated. It is not a timeout and not a fallback chosen when the wait is long — it is the immediate answer to "can any of these proceed right now?" This gives Go its non-blocking channel idiom without timing tricks, and it is the mechanism behind checking len(ch)-style conditions without the racy alternative of reading len and then sending (between the check and the send, another goroutine may have filled the buffer).

The other classic use makes select do double duty as timeout:

select {
case ev := <-events:
	handle(ev)
case <-time.After(5 * time.Second):
	return errors.New("no event within 5s")
}

time.After returns a channel that delivers once after the duration; select then waits on either an event or the tick. It reads beautifully in one-shot request handlers. In a loop it is a trap: each iteration allocates a new timer that lives until it fires — a slow producer leaks timer entries proportional to iterations (Go 1.23's garbage-collectible timers soften this, but a time.NewTimer you Stop() explicitly remains the pattern that works on every version, and Goroutine Leaks revisits the failure mode). For a loop, reset one timer:

t := time.NewTimer(idleLimit)
defer t.Stop()

for {
	select {
	case j := <-jobs:
		if !t.Stop() { <-t.C } // drain if it already fired
		t.Reset(idleLimit)
		process(j)
	case <-t.C:
		return nil // idle shutdown
	}
}

Note what default is not appropriate for: a consumer that must wait for work. select with default on a jobs channel returns immediately when empty, so the loop spins at 100% CPU unless the caller sleeps — replacing a parked goroutine with a busy loop, which is strictly worse. Blocking select costs nothing while idle; use default only when "not ready" is itself a meaningful answer.

A subtlety from Closing Channels turns select into a control-panel: a receive on a closed channel is always ready. Once someone closes done, case <-done: fires on the very next select evaluation — even if the select was already parked, even if it is evaluated a million more times. That permanence is what makes shutdown composable:

func aggregate(in1, in2 <-chan int, done <-chan struct{}) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for {
			select {
			case v := <-in1:
				out <- v
			case v := <-in2:
				out <- v
			case <-done:
				return
			}
		}
	}()
	return out
}

Three structural points separate good shutdown selects from broken ones.

Every blocking operation in the body needs its own escape hatch. The out <- v inside the loop blocks if the downstream consumer is slow — and while it blocks, this goroutine is not selecting on done. The complete version wraps that send too:

case v := <-in1:
	select {
	case out <- v:
	case <-done:
		return
	}

The rule generalizes: any channel operation a goroutine performs while cancellation should be possible must itself be inside a select that includes the done case. One unguarded blocking send is one goroutine that misses shutdown.

Random selection among ready cases prevents starvation but not fairness guarantees. If in1 is always ready and in2 rarely is, each select iteration has an equal chance of picking either among those ready at that moment — in2 does not get priority for having waited. Workloads that need fairness (round-robin over N producers) need explicit rotation logic; select guarantees only that no ready case is systematically starved by source order.

Interaction with nil channels, once directions enter the picture: assigning a case's channel variable to nil disables that case — select blocks on it forever, exactly as if the case were removed. People use this to turn off an input branch at runtime (a stage that stops reading from one source) without rewriting the select. A disabled case contributes nothing to readiness, so the select can still proceed on the others — a nil case alone with no default blocks, same as any permanently unready case.

The mental model: select is a wait on N conditions plus optional escape routes — default for immediate answers, a done channel for broadcast interruption, nil for a branch compiled out at runtime. context.Context later replaces hand-rolled done channels with a standard one, but every context-aware function you read is built on exactly this shape: select { case <-ctx.Done(): ...; case work <- job: ... }.

select borrows switch's case syntax but not its fall-through rules, and two control-flow surprises account for most review comments.

break inside select does not break the loop. It breaks the select — which already ended when the case body finished. So this shutdown check does nothing:

for {
	select {
	case <-done:
		break // exits the SELECT, not the for — loop continues forever
	case j := <-jobs:
		process(j)
	}
}

The loop spins on, immediately selects done again (it is closed, hence always ready), and breaks the select again — a hot infinite loop instead of a shutdown. The fix is return, or if the select sits inside a labeled loop you need to leave:

workers:
	for {
		select {
		case <-done:
			break workers // labeled break leaves the for
		case j := <-jobs:
			process(j)
		}
	}

Most code sidesteps the issue by making the case body return outright; reach for a labeled break only when work must continue after the loop.

A nil channel in a case is disabled, not broken. This looks like a bug and behaves like a feature:

var pause <-chan int // nil: this case can never become ready

for {
	select {
	case v := <-active:
		process(v)
	case v := <-pause: // never selected
		process(v)
	case <-done:
		return
	}
}

Assigning pause = someChannel later enables the branch mid-flight; assigning it back to nil disables it again. Structs with directional fields (Directional Channels) use this to make optional inputs — a nil input channel means "this stage has no second source," and the compiler plus select semantics enforce it instead of an if src != nil wrapper around the whole receive.

The related trap is the reverse: a nil channel you meant to assign. var out chan<- Result passed without initialization makes every case out <- r: permanently unready — the select quietly waits on the other branches and your results vanish into a branch that never fires. Because nil cases block silently rather than panic, this fails as lost data or hung shutdown, never as a crash. The debugging habit worth building: when a select behaves as if a case "isn't wired up," print the channel variables — a nil pointer there explains more select mysteries than any other single check.