Select patterns

Canonical guidance

• keep each select arm meaningful and bounded
• include cancellation paths in long-lived loops
• do not assume deterministic fairness across ready cases

Use when

• cancellation-aware workers
• multiplexing multiple channels
• timeouts and shutdown signals

Avoid

• default branches that spin and burn CPU
• giant select blocks mixing unrelated concerns
• assuming one ready case always wins first

Preferred pattern

for {
	select {
	case <-ctx.Done():
		return ctx.Err()
	case item, ok := <-in:
		if !ok {
			return nil
		}
		handle(item)
	}
}

Anti-pattern

• adding a default just to avoid blocking when the caller actually wanted backpressure

Explanation: This anti-pattern is tempting because non-blocking code feels safer, but it often turns coordination into dropped work or CPU spin.

Why

• select is precise when it models real coordination, not when it is used to dodge blocking semantics