Leaking Goroutines

Admittedly this should be classified in a duhhh category of knowledge, but...

I recently wrote code that used the useful atomic.Value type to support hot reloading a configuration. In doing so, I introduced a goroutine (and memory) leak.

The bug was 100% my fault, and didn't have anything to do with atomic.Value other than the fact that it's the type of issue you'll most likely run into when swapping out values like that. Consider this code:

update

@dqminh pointed out that instead of introducing the new stop channel, we could simply have called close on the existing queue. For the above, this is definitely a more elegant solution. However, it's possible that the your worker code won't be channel-bound, say: