On Thursday, August 31, 2017 at 3:23:02 PM UTC-5, Ian Lance Taylor wrote: > > On Thu, Aug 31, 2017 at 7:45 AM, Jason E. Aten <[email protected] > <javascript:>> 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. >
Nice. Thanks Ian! > > > > 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. > Good point. I see from the intro blog on the race detector that // +build race and // +build !race as in the example https://codereview.appspot.com/6624059/patch/4005/4 could be used for/instead of "annotation" to avoid the race detector freaking out about send and close racing. -- 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.
