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

[Rustin170506]

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.

[Rustin170506]

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)
	}
}

[Rustin170506]

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

[Rustin170506]

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.

[Rustin170506]

Then we may have to just close out chan and delete all data immediately.

[changkun]

Then we may have to just close out chan and delete all data immediately.

Deleting all data immediately may not be a good idea because there may be a receiver waiting for all data.