Hacker News Reader

Comment by jgrahamc | Hacker News Reader

Darn. I just knew that when I was extracting some showable bits of code from Railgun and making simple examples that I'd mess something up. The third Gist in there isn't anything like the Railgun code (it was just showing the use of the Counter object) and, as you point out, it is not thread safe.

I will update the blog post with a version that uses a channel and select to send the count.

View on HN

Hi John, https://gist.github.com/3039932 has problems; w.Count() is evaluated every time around the for-loop even if the result isn't sent down the count channel. See http://play.golang.org/p/pbCX13my0q where I've altered lines 60-62 yet there's still only "29 bytes written".

Yes, that's correct. It does look a bit odd doesn't it. As you say it's because the w.Count() gets evaluated by the select each time around the loop and so the count gets reset to 0.

Probably the best way to fix that is to make Count() non-destructive and have an explicit Clear function that gets called when a count has been delivered.

Like this: http://play.golang.org/p/LWVvdhwBiQ

Since this blog post is likely to be around for a while I will update the code.

It's almost like sometimes it would have handy to do

    case ch <- defer foo():

and only have foo() be evaluated if ch is ready for writing and also chosen amongst the cases. As the (fixed) code stands either the Sprintf() and Sum() or Count() is wasted on each iteration. I suppose in some cases you can calculate the initial values before the for-loop and then replenish them in the case: when they're used.

Have you done the update now? Only there's a NewCounter() that's called but not defined and the text says "it can be passed to counter.New".

Reply on news.ycombinator.com