4 ms·
Sending channels over channels (i.e. chan chan) is a common pattern for publish-subscribe systems, e.g. https://github.com/twpayne/go-pubsub/blob/master/pubsub
by twp 2y ago
Sending channels over channels (i.e. chan chan) is a common pattern for publish-subscribe systems, e.g.
https://github.com/twpayne/go-pubsub/blob/master/pubsub.go https://github.com/twpayne/go-pubsub/blob/master/pubsub.go
- cedws 2y agoThat’s some pretty Go code, I like it. Just out of interest, why have a channel for subscribe/unsubscribe? Did you want to avoid a mutex on the subscriber map?
- distortionfield 2y agoNot the OP but yeah, that’s usually the reason I reach for a channel in this case. A mutex or wait group is just begging for a deadlock to rise up when you least expect.
- Thorrez 2y agoCan't channels deadlock too? Sending or receiving on a channel will block by default until the other side receives/sends the value if the channel is unbuffered, or it's buffered but the buffer is full. You have to write extra code to make it non-blocking; the pubsub example under discussion is blocking. I don't see how switching the discussed code to a mutex would make it any more blocking or deadlock prone. I found a bug in production caused by the author not realizing a send on a channel can block.