4 ms·

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 def

by SmooL 6y ago

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.

tedunangst 6y ago
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.
- konart 6y ago
  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.
- jrockway 6y ago
  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.)

by SmooL 6y ago

tedunangst 6y ago

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.

konart 6y ago
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.
jrockway 6y ago
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.)