Channels

A channel is a typed conduit that passes values between goroutines. An unbuffered channel synchronizes — a send blocks until a receiver is ready. A buffered channel (make(chan T, n)) holds up to n values; send blocks only when the buffer is full.

A channel made with make(chan T) is a typed conduit between goroutines. You send with ch <- v and receive with v := <-ch; the arrow always points in the direction the value moves. On an unbuffered channel the send blocks until some other goroutine is ready to receive, and the receive blocks until a value arrives, so the two goroutines rendezvous and synchronize at that point. The element type T is fixed at creation.

An unbuffered channel has capacity 0, so every send blocks until a receiver is ready to take the value — the send and receive must rendezvous. A buffered channel from make(chan T, n) holds up to n values, so the first n sends complete without any waiting receiver and only block once the buffer is full. This decouples sender and receiver up to n items: the producer can run ahead, smoothing bursts, but does not give unlimited slack.

select waits until one of its channel cases is ready; if several are ready it picks one uniformly at random. With a default case it never blocks — if no case is ready, default runs at once. An empty select{} blocks forever.

Use the comma-ok form v, ok := <-ch: ok is false once the channel is closed and drained, and v is the element type's zero value. A for range ch loop is the idiomatic alternative — it exits automatically when the channel closes.

Both a send and a receive on a nil channel block forever — the operation never proceeds and never panics. A zero-value channel variable is nil. This is sometimes used deliberately in select to disable a case by setting its channel to nil.

for v := range ch keeps receiving values one by one and only ends when the channel is closed and drained. close(ch) is the sender's signal that no more values will come; ranging over an unclosed channel blocks forever once it is empty. A receive from a closed channel returns the element's zero value with ok == false, which is exactly what stops the loop. Only the sender should close, and closing twice or sending after close panics.

Receiving from a closed channel returns the zero value with ok == false, so (1) gives v == 0, ok == false. Sending on a closed channel panics with send on closed channel, so (2) panics. Closing an already-closed channel also panics, so (3) panics. Rule: the sender closes, never the receiver, and only once.

context.Context carries cancellation signals, deadlines, and request-scoped values across API boundaries. Calling a cancel func or hitting a deadline closes the context's Done() channel; that close propagates to every derived child context, so all of them observe cancellation.

A channel is a pointer to a runtime hchan struct: a ring buffer (buf with sendx/recvx indices and element counts), two wait queues of blocked goroutines (sendq, recvq), and a mutex. Every send/receive takes the lock; if the operation cannot proceed the goroutine parks on a queue and is later woken by its peer. Closing sets a flag and wakes both queues.

It deadlocks: fatal error: all goroutines are asleep - deadlock!. An unbuffered send blocks until a receiver is ready, but the only goroutine is blocked on the send, so the receive never runs. Fix: send from a separate goroutine, or use make(chan int, 1).

Sending on a closed channel panics immediately with send on closed channel. Avoid it by making one owner responsible for closing, and never closing from a receiver or from multiple senders. The sender side decides closure; the receiver only detects it via comma-ok.

for v := range ch keeps receiving until the channel is closed. The producer sends 1 and 2 but never calls close(ch), so the consumer blocks forever after draining them, wg.Done() never runs, and wg.Wait() blocks too — deadlock. Fix: close(ch) after the last send.

It prints 02468. With capacity 1 on a single goroutine the send and receive cases alternate: on an empty buffer only the send is ready (buffers i, prints nothing); next iteration the buffer is full so only the receive is ready (prints the stored even value). With an unbuffered channel neither case is ever ready on one goroutine, so the program is a fatal error: all goroutines are asleep - deadlock.

It prints 6. Go evaluates the two-operand expression left to right: the first <-worker() calls worker() (starting goroutine #1) and then blocks 3s receiving from it. Only after that completes does the second worker() even start, then blocks another 3s — so they run sequentially, ~6s total. To overlap them, start both first: c1, c2 := worker(), worker(); <-c1; <-c2 → ~3s.

select over two cases: case <-ctx.Done(): return false and case <-timer.C: return true. Don't use time.After, which leaks the underlying timer until it fires; instead t := time.NewTimer(d); defer t.Stop() so a cancellation reclaims the timer immediately.

Run unpredictableFunc in a goroutine that sends its result on a buffered channel of capacity 1, then select over that channel versus ctx.Done(). The buffer is load-bearing: with an unbuffered channel the worker blocks forever on the send after a timeout, leaking the goroutine. If ctx has no deadline, wrap it with context.WithTimeout and defer cancel().

A cancelCtx holds a lazily-created Done channel and a set of child contexts; cancel closes that channel and recursively cancels children. A timerCtx wraps it with a time.Timer that fires cancel at the deadline. valueCtx is a single key/value node; lookups walk the parent chain.

Two bugs. The closing goroutine is written go func(){ wg.Wait(); close(out) } with no trailing (), so it is declared but never launched — out never closes and range merge(...) deadlocks. Second, the worker closure captures the loop variable c, so pre-1.22 every goroutine ranges over the same last channel. Fix: call the closer with (), and pass c as an argument (or rebind it).

A goroutine leaks when it blocks forever on a channel send or receive nobody will satisfy — e.g. a worker sends a result after its caller already returned. Prevent it by giving every blocking operation an exit: a select on ctx.Done() or a buffered result channel.

Start one goroutine per input channel, each range-ing its channel and forwarding every value to a shared out. A sync.WaitGroup counts the forwarders; a separate goroutine calls wg.Wait() then close(out), so the output closes exactly once after all inputs drain. Return out immediately. Ranging the inputs and closing out only after Wait avoids both a send-on-closed panic and a goroutine leak.