On Thursday, August 31, 2017 at 7:40:23 AM UTC-5, Konstantin Khomoutov wrote: > > On Thu, Aug 31, 2017 at 05:08:23AM -0700, Jason E. Aten wrote: > > > A question for those familiar with the runtime internals of channel > close > > and channel receive: > [...] > > Will closing a channel in the middle of a send introduce the possibility > of > > data corruption? The language spec guarantees a panic, and that panics > > can be recovered, but would a *reader* of ch above ever see incorrect > data? > > 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? I dislike sync.Cond, and prefer channels, but giving up 40-50% performance means everyone who cares about network performance (e.g. http2, x/crypto/ssh) currently ends up using sync.Cond. I have a suggestion for sticky value send/receive via the `ch <~ 12` sticky send operator to help with this (https://github.com/golang/go/issues/21165#issuecomment-325471204) but that's clearly more into the Go2 territory. -- 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.
