[...] > > AFAIK, all operations on a channel happen in-order and are fully > > serialized. That is, close() will wait until the currently active > > operation > > is active, if any. > > > > In other words, close() on a channel is not like closing an OS file > > descriptor -- even though the operation's names are the same. > > > > > It looks like any send happens after the channel mutex is grabbed here > https://github.com/golang/go/blob/master/src/runtime/chan.go#L181 > > and the release of senders on close also happens after grabbing the channel > mutex here > https://github.com/golang/go/blob/master/src/runtime/chan.go#L330 > > so at the moment this appears to be safe. > > I think it might be worth proposing an addition that the language spec (Go > 1 or Go 2) to guarantee this is safe on into the future. > Unless that isn't necessary because some part of the spec already implies > this?
Currently the spec states: | A single channel may be used in send statements, receive operations, and | calls to the built-in functions cap and len by any number of goroutines | without further synchronization. Books and tutorials on Go typically state something like "close() is a send operation" -- meaning that closing a channel unblocks all the goroutines currently being blocked on it -- thus clearly having "send" semantics. There even exist an idiom of using a channel for broadcasting a single event to a number of goroutines. Still, I don't see any specific wording regarding this in the spec -- neither in its section on channels nor in its section on the close() function. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
