chann: unbounded channel may result in a spin loop if there is no receiver after the close

[0xPoe]

chann/chann.go

Line 176 in 619cda1

default:

If not will it be any problem?

[changkun]

If there is no receiver, this default branch can prevent the goroutine block forever at the close.

If there is a receiver, the receiver will always receive all unsent data because select will always use case ch.out <- q[0] branch.

[0xPoe]

If there is no receiver, this default branch can prevent the goroutine block forever at the close.

Won't the default branch cause a cpu spin if executed?

[changkun]

Interesting. Looks like a bug. Thanks for reporting!

[changkun]

I believe ad8c992 did not solve the issue but actually introduced a different bug. Consider this test:

func TestUnboundedChannRecvAfterClose(t *testing.T) {
	var wg sync.WaitGroup
	ch := chann.New[int]()

	wg.Add(1)
	c := 0
	go func() {
		for range ch.Out() {
			c++
		}
		wg.Done()
	}()

	for i := 0; i < 2048; i++ {
		ch.In() <- 42
	}
	ch.Close()

	wg.Wait()
	if c != 2048 {
		t.Fatalf("not all elements are received after channel being closed, want %v got %v", 2048, c)
	}
}

[0xPoe]

How about we just delete deafult? Leaving the decision about the data to the consumer?

[0xPoe]

ch.In() <- 42

Is this a typo?

[changkun]

How about we just delete deafult? Leaving the decision about the data to the consumer?

Removing the default will lead to leaking goroutine. We must always guarantee the processing goroutine will terminate even if there is no receiver.