去通道缓冲和死锁

Considering the following code block, it's expected to throw an error due to reaching a the buffer limit:

package main        

import (
    "fmt"
    "time"
)

func main() {

    burstyLimiter := make(chan time.Time, 4)

    for i := 0; i < 5; i++ {
        burstyLimiter <- time.Now()
        fmt.Println("adding to burstyLimiter")
    }

}

But when I try the exact block with the following, it blocks instead of throwing an error. I am tying to understand this behavior. Thanks for your time.

package main

import (
    "fmt"
    "time"
)

func main() {

    requests := make(chan int, 5)
    close(requests)

    limiter := time.Tick(time.Millisecond * 200)

    for req := range requests {
        <-limiter
        fmt.Println("request", req, time.Now())
    }

    burstyLimiter := make(chan time.Time, 4)

    for i := 0; i < 5; i++ {
        burstyLimiter <- time.Now()
        fmt.Println("adding to burstyLimiter")
    }
}

You get a panic, when the Go runtime discovers that all goroutines are in a deadlock: waiting for some "internal" event, internal in the sense another goroutine is expected to trigger it.

This is what you get in the first program.

In the second program, you have a "hidden" goroutine, created by the call to time.Tick. This goroutine sends ticks on a channel, but does not block on it ("drops ticks to make up for slow receivers" form the docs). So you have at least one running goroutine in the second example, which occasionally blocks on external event (timer tick), thus the whole system is not deadlocked form the point of view of the Go runtime deadlock detection.