←back to thread

Problems with Go channels (2016)

(www.jtolio.com)
159 points mpweiher | 2 comments | 13 Apr 25 05:43 UTC | HN request time: 0.412s | source
Show context
ricardobeat ◴[13 Apr 25 11:22 UTC] No.43671958[source]▶
Strange to go all this length without mentioning the approaches that solve the problem in that first example:

1. send a close message on the channel that stops the goroutine

2. use a Context instance - `ctx.Done()` returns a channel you can select on

Both are quite easy to grasp and implement.

replies(2): >>43671984 #>>43672081 #
sapiogram ◴[13 Apr 25 11:49 UTC] No.43672081[source]▶
You've misunderstood the example. The `scores` channel aggregates scores from all players, you can't close it just because one player leaves.

I'd really, really recommend that you try writing the code, like the post encourages. It's so much harder than it looks, which neatly sums up my overall experience with Go channels.

replies(3): >>43672616 #>>43673034 #>>43673193 #
1. ricardobeat ◴[13 Apr 25 14:48 UTC] No.43673193[source]▶
In both examples, the HandlePlayer for loop only exits if .NextScore returns an error.

In both cases, you’d need to keep track of connected players to stop the game loop and teardown the Game instance. Closing the channel during that teardown is not a hurdle.

What am I missing?

replies(1): >>43674082 #
2. guilhas ◴[13 Apr 25 16:46 UTC] No.43674082[source]▶
I think nothing

I was thinking the same, the only problem is the author not keeping track of players

On HandlePlayer return err you would decrement a g.players counter, or something, and in the Game.run just do if !g.hasPlayers() break close(g.scores)

The solution requires nothing special, just basic logic that should probably be there anyway

If anything this post shows that mutexes are worse, by making bad code work