[frou_dh]

Something that doesn't sit right with me is the use of a "channel of bool" when the receiving goroutine doesn't actually care whether true or false is sent. It muddies the API to force the sender to choose one of two values when all that's really wanted is an amorphous signal.

e.g. in http://talks.golang.org/2013/bestpractices.slide#25 , the first case in the select will trip regardless of which value arrives, yet the sender was still made to choose one.

[shurcooL]

  A channel may be closed with the built-in function close; the multi-valued
  assignment form of the receive operator tests whether a channel has been closed. [1]

Given that is available, why is the use of a separate bool quit channel preferred?

[1] http://golang.org/ref/spec#Channel_types

[frou_dh]

In the link, the quit is acknowledged, so one side closing the channel straight off the bat wouldn't allow for that.

[dragonwriter]

A quit channel (that is not receive only) can be used to send back a quit message by a goroutine that only has a receive-only view of the main data channel; close() can't be called on a receive-only channel.

[bradfitz]

Just sending "true" as a signal is a convention, but some people prefer something like http://play.golang.org/p/oXapo7R4RX

[frou_dh]

Cool, I like that. In some ways, it would be nice if there were a friendly alias for struct{} as part of the language, but I suppose it's hard to come up with a good general name for that.

[lmm]

Many languages call it unit or ().

[frou_dh]

Hah, I was just about to edit my comment to mention unit after doing some reading :)

[exch]

I'll add that the reason for using `struct{}` over `bool`, is that an empty struct occupies 0 bytes, whereas a boolean occupies 1.