It seems that you understand why you are seeing the behavior you reported, but you are questioning whether the spec either does or should guarantee that reading from a channel with a goroutine waiting to send on that channel will fill the buffer as an atomic part of the read.
As others have said, the spec does not guarantee this. I would like to add that I believe it shouldn't. Suppose goroutine A is currently blocked waiting to send on a channel. Now goroutine B reads from that channel. If the refill of the channel must happen atomically with the read from that channel, now goroutine B must be put in a blocked state waiting for goroutine A to finish its send. This contradicts the spec at [1] which states ...communication succeeds without blocking if the buffer is not full (sends) or not empty (receives). If you think about how this is likely to be implemented (including considerations for GOMAXPROC and multicore vs single core systems), you should realize that, while it would be possible to implement atomic-refill, it would give no (or very little) benefit and might have undesirable performance effects. As an aside, I think the reason Jake is seeing 100 lines of output and you only see 1 is likely to be the difference between GOMAXPROC=1 and greater than 1. If GOMAXPROC=1, the scheduler may force a running goroutine to yield after receiving, but before returning from the receive operation. In other words, the receive happens without blocking, but the scheduler thinks that is a convenient point for giving another goroutine an opportunity to run. ...Marvin [1] https://golang.org/ref/spec#Channel_types -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
