On Thu, Aug 31, 2017 at 7:45 AM, Jason E. Aten <[email protected]> wrote: > On Thursday, August 31, 2017 at 9:23:58 AM UTC-5, Konstantin Khomoutov > wrote: >> >> 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. > > > Looks like it. So relying on this behavior could result in future breaks. > Although I'm > not sure I see how, racy stuff always has a way of surprising.
The only race here is between the send and the close, and there is no possibility of data corruption. A close is a send operation that doesn't wait for a receiver. So if the close happens first, then the channel is closed, and any future sends, including any sends currently active, are an error that will cause a run-time panic. If the send happens first, there is no confusion. > And actually that's the only downside I see at the moment: the race detector > hates (points out a race) using this technique. > > Is there any way to annotate to tell the race detector not to freak out? I suppose that arguably we could say that there is no race between send/close any more than there is a race between send/send. Of course, for most programs, a race between send/close indicates an error. So it does seem to me that the race detector is doing the right thing in general, even if for your program it is reporting an unhelpful error. Ian -- 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.
