Hacker News Reader

Comment by ben509 | Hacker News Reader

> Writing to and reading from a nil channel blocks forever.

Have any experienced Go devs found cases where this behavior is useful?

Personally, I never read or write a channel without some sort of time bound, so this behavior doesn't really bother me:

    select {
    case foo := <-whateverCh:
        log.Printf("hey a foo: %v", foo)
    case <-ctx.Done():
        log.Println("the user doesn't care about the answer anymore, so let's not leak the goroutine")
    }

Actually yes - it implies that if the read/write executes, then the read/write was successful.

In practice, in cases where a nil read/write could happen, a default "fall through" option on a select statement is used.

They could have made the original interface return a possible error for reading/writing, in line with regular go error handling, but opted instead to use more channel-based conventions.

I think the question is when would it be useful outside of select. Once you block on nil channel, there's no way to unblock, which doesn't seem helpful.

They only case I can think of right away is some kind of process that should not die after the execution and wait until the user kills it by hand after reading through execution report.

Such is the danger of blocking indefinitely. I think every Go programmer's first concurrent app eventually crashes because it runs out of memory, memory used by goroutines that are waiting for an answer that will never come. When you write "foo := <-ch", you're saying "I am willing to wait forever for an answer". Unfortunately, actual computers in the real world don't have the resources to wait forever.

Honestly, I see the ability to block indefinitely as a bug in the language. An improved language would probably "result, err := <(ctx)- ch", i.e. make it impossible to block without something bounding the duration of the block. (Also kill sync.Mutex. 100% of Go concurrency bugs are from people mixing mutexes and channels.)

(As an alternative, the runtime could be smarter about goroutines that have blocked forever. I am not sure exactly what it would look like, but the hypothetical first Go program I talk about above would probably be saved by something that killed goroutines that were waiting for a message from a TCP connection that is long gone. I think if it were easy to do right, it would have been done, though.)

You can disable/pause channels using this. "Advanced Go Concurrency Patterns" by Sameer Ajmani explained this back on 2013.

Yep, it's very useful for channel-based state machines, you can turn transitions on and off between states.

Reply on news.ycombinator.com