3 ms·
Avoid channels except for straight forward, producer-consumer workflows. Use mutexes and other traditional concurrency primitives for other stuff. Channels are
by avl999 5y ago
Avoid channels except for straight forward, producer-consumer workflows. Use mutexes and other traditional concurrency primitives for other stuff. Channels are a huge shotgun with caveats.
- gilgad13 5y agoI agree, with the addition that closing an unbuffered `<-chan struct{}` is a good way to do broadcast notifications (a. la. the context package). As evidence that channels should be used rarely, and only in small scopes, consider the number of places chan is used in the standard library.
- lanstin 5y agoThe thing about channels is, while they might be slow for tight inner loop type compute code, it lets you scale across all the cores very linearly. And, given a channel to flow the work thru, you can manage the number of workers at each stage however you like - growing with more load, dropping work with more load, back pressure with more load. All concisely and explicitly. And a lot of network server things are classic producer/consumer things, so it’s great to have a solution for that where you get concurrency without any thread worries.
- bashery 5y ago+1