4 ms·
Any go enthusiasts mind explaining this one? It looks like a very strange syntax: No, Andrew described this case: > should be rewritten as, >
by mrj 16y ago
Any go enthusiasts mind explaining this one? It looks like a very strange syntax:
No, Andrew described this case:
> should be rewritten as,
> select {
> case ch <- v:
> // sent
> default:
> // not sent
> }
Without the default, the select statement becomes blocking.
- marketer 16y agoNobody really uses the non-blocking channel receive operations. I didn't even know it existed until now. Selecting on multiple channels is, however, is used very often, so this fits that paradigm quite well.
- justinlilly 16y agoWhat does it actually do? Executes the body of the case for the channel which has output?
- teejae 16y agoYes, that's right, and only once. It's like a switch statement, only using inputs instead of fixed cases. It does make sense to have the blocking version, if there's nothing else to do.
- jlouis 16y agoThere is also a fairness point: If more than one channel is available, which one to go is selected in a fair way. This is important so a channel at the top can not flood and monopolize the selective communication primitive.
- btilly 16y agoSee http://golang.org/doc/go_spec.html#Select_statements http://golang.org/doc/go_spec.html#Select_statements for the relevant documentation. What select does is selects which communication option to do, and it blocks until one of the options is available. So if you select on one option, you will block until you do that. But default is always available, so now you don't block.