[go-nuts] (Un)Expected compiler behavior on named/unnamed parameters of interface functions

I think that there is inconsistency in the way Go compiler report error regarding name/unnamed parameters. This is a bit hard for me to explain in words so please check out this short snippet first: https://play.golang.org/p/Sg0DtCtgF2 Is this unexpected behavior or it's just me that's feeling

Re: [go-nuts] (Un)Expected compiler behavior on named/unnamed parameters of interface functions

7, Ian Lance Taylor wrote: > > On Fri, Aug 11, 2017 at 11:03 AM, Penguin Enormous > <kimkh...@gmail.com > wrote: > > > > I think that there is inconsistency in the way Go compiler report error > > regarding name/unnamed parameters. This is a bit hard for me to e

[go-nuts] sync.Cond implementation

Hi Gophers! I'm trying to understand line 522 of src/runtime/sema.go : if atomic.Load() == atomic.Load() { > > ... I can't help but thinking, what guarantee that the atomic read of l.wait won't return stale value,

Re: [go-nuts] sync.Cond implementation

Could it be this: Initially wait == notify == 0 Waiter Signaler 479 atomic.Xadd(, 1) = 1 522 atomic.Load() = 0 atomic.Load() = 0 523 return (because those above are equal) 485 notifyListWait(l, t) (blocked forever) But looking at your answer, I see that you may imply certain race

Re: [go-nuts] sync.Cond implementation

Much appreciated for all the great advises from everyone. Or to be more precise: it is crucial you load wait before notify and the > check for equality can only happen if the routine "caught up". Also, your > proof must hold if you remove the fast-path check in line 522. > Why is it crucial to