17 — Channels

// A channel is a pointer to a runtime hchan struct:
//   type hchan struct {
//       qcount   uint           // number of buffered elements
//       dataqsiz uint           // buffer capacity
//       buf      unsafe.Pointer // circular buffer (for buffered channels)
//       elemsize uint16         // element size in bytes
//       sendx    uint           // send index in circular buffer
//       recvx    uint           // receive index in circular buffer
//       recvq    waitq          // list of goroutines waiting to receive
//       sendq    waitq          // list of goroutines waiting to send
//       lock     mutex          // protects the hchan struct
//   }
//
// Memory per channel:
//   - hchan struct: ~96 bytes
//   - Buffer (buffered): capacity × elementSize bytes
//   - Each blocked goroutine: ~2KB stack (on the sendq/recvq)
//
// A channel with 1000 ints: 96 + 1000×8 = ~8KB
// A channel with 1M structs (100 bytes each): 96 + 1M×100 = ~100MB
//   — be careful with large buffers for big element types

💡 Tips & Tricks

• Idiom: use chan struct{} for signal/done channels — zero bytes, signals "event only, no data." close(done) broadcasts to all receivers simultaneously.
• Idiom: the sender closes the channel — the receiver never closes (it doesn't know if other senders exist). For multiple senders, use a coordinator (WaitGroup + close after all done).
• Idiom: use directional channel types in function signatures (func f(in <-chan int, out chan<- int)) — documents intent, compiler enforces. Convert bidirectional to directional implicitly on call.
• Idiom: use a nil channel in select to disable a case dynamically — assigning nil makes that case block forever (never fires). Pattern for state machines and conditional send/receive.
• Idiom: use buffered channels to decouple producer/consumer when rates differ — a buffer absorbs bursts. Don't use buffering to "fix" a deadlock; size the buffer deliberately (worker count or expected burst).
• Debug: len(ch) and cap(ch) are rarely useful for synchronization — the values change immediately as goroutines send/receive. Don't use them for sync logic. Use them only for monitoring/metrics.

⚠️ Edge Cases & Gotchas

• Sending to a closed channel panics: only the sender closes, and only after all sends. Receiving from a closed channel is fine (zero value, ok=false).
• Closing a closed channel panics: double-close is a runtime panic. Use sync.Once if closing might be called multiple times.
• Closing a nil channel panics: var ch chan int; close(ch) → panic.
• Receiving from a nil channel blocks forever: var ch chan int; <-ch hangs. Useful in select (disables the case), a bug if unintended.
• Unbuffered channels are synchronous: ch <- v blocks until a receiver is ready. A sender with no receiver deadlocks. Ensure a receiver is running or use a buffer.
• Buffered channels hide deadlocks temporarily: a buffer full of sends with no receiver eventually deadlocks. The buffer delays, not prevents.
• range over a channel blocks until close: for v := range ch never returns unless ch is closed. Forgetting to close leaves the range goroutine stuck.
• Multiple senders, one closer: if multiple goroutines send, none should close directly. Use a coordinator or context to signal shutdown.
• len(ch)/cap(ch) changes immediately: the values are stale by the time you use them. Don't use for synchronization.
• Channel capacity is fixed: make(chan T, n) — can't resize. Pick the right capacity at creation.

🧠 Quick Quiz

func main() {
    ch := make(chan int, 2)
    ch <- 1
    ch <- 2
    close(ch)
    v1, ok1 := <-ch
    v2, ok2 := <-ch
    v3, ok3 := <-ch
    fmt.Println(v1, ok1)
    fmt.Println(v2, ok2)
    fmt.Println(v3, ok3)
}