Channels
in Depth

• Part 1 only got us to the unit of execution — no way to pass values yet
• A shared variable + mutex works, but a human has to remember the lock order
• Go's answer is CSP — hand the value over and ownership goes with it
• A channel solves communication and synchronization at once. Nothing to lock

// shared memory — humans keep the lock order
mu.Lock()
result = 42
mu.Unlock()

// channel — hand it over, ownership goes too
ch := make(chan int)
go func() { ch <- 42 }()
v := <-ch

• make(chan T) — only T flows. Anything else is a compile error
• The second argument is the buffer size. Omit it and it's 0
• That one number changes the synchronization: 0 is a handshake, 1+ is a queue
• The zero value is nil. A nil channel blocks send and receive forever

ch := make(chan int)        // unbuffered
ch := make(chan string, 5) // buffered (5 slots)

ch := make(chan Result)     // structs work too
ch := make(chan chan int)   // channels of channels too

var ch chan int             // nil — never proceeds

• Arrow on the right of the channel is a send — ch <- v
• Arrow on the left of the channel is a receive — v := <-ch
• You needn't take the value. A bare <-ch means "wait until one arrives"
• In the two-value form v, ok := <-ch, ok tells you if the channel is still alive

func TestChannelSendReceive(t *testing.T) {
    ch := make(chan int)

    go func() {
        ch <- 42 // send
    }()

    value := <-ch // blocks until the send
    assert.Equal(t, 42, value)
}

• cap(ch) — the buffer capacity fixed at creation. It never changes
• len(ch) — how many values are queued in the buffer right now
• An unbuffered channel is always cap 0, len 0
• Fine for monitoring and logs. But never use them for flow control

ch := make(chan string, 5)

assert.Equal(t, 5, cap(ch)) // capacity
assert.Equal(t, 0, len(ch)) // values waiting

ch <- "a"
ch <- "b"

assert.Equal(t, 5, cap(ch))
assert.Equal(t, 2, len(ch))

• chan<- int — send-only. Receiving is a compile error
• <-chan int — receive-only. Sending or closing is a compile error
• The runtime cost is zero. Purely a compile-time check
• Mostly used on function parameters and return types. Rarely on variables

chan int     // bidirectional
chan<- int   // send-only — put in only
<-chan int   // receive-only — take out only

func produce(ch chan<- int) { ch <- 1 } // OK
func consume(ch <-chan int) { <-ch }   // OK

func bad(ch <-chan int) { close(ch) } // compile error

• It doesn't remove the channel. Values left in the buffer all still come out
• It means "no more sends", not "all values have arrived"
• So only the sender can close — the receiver has no way to know the end
• You needn't always close. It's needed when someone reads with range

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch) // no more sends

fmt.Println(<-ch) // 1 — leftovers intact
fmt.Println(<-ch) // 2
fmt.Println(<-ch) // 0 — all drained

• for v := range ch — waits for values and pulls them out one by one
• It ends in exactly one case: the channel closing. It doesn't count values
• Forget the close and it blocks forever — the classic cause of goroutine leaks
• Same as writing v, ok := <-ch, but it does the ok check for you

ch := make(chan int, 5)
go func() {
    for i := 1; i <= 5; i++ {
        ch <- i
    }
    close(ch) // without it range never ends
}()

for v := range ch { // 1 2 3 4 5
    out = append(out, v)
}

• struct{} has no fields, so it's 0 bytes — the type shows you mean to carry no value
• With chan bool, "what does true mean, and false?" always follows
• Signals have no reason to pile up, so they're usually unbuffered
• By convention they're named done, quit, ready

done := make(chan struct{})

go func() {
    // do the work...
    close(done) // done signal
}()

<-done // wait until it's done