Actually, a buffered channel alone is not enough... A more robust solution is to move the shutdown branch in jobDispatcher into a function; then call this function in a goroutine of its own right after you create shutdown channel. That will prevent the message sending and channel closing from deadlocking. You should also consider what you want to do with the messages still in the channel buffer at shutdown (probably drain the buffer and feed the messages back into a queue), and the possibility that the channel was closed between its successful retrieval from the map and the sending operation (recover from the panic and re-queue the message). Most likely, you would extract the other select branch from jobDispatcher into its own function. Something along the lines of this (not tested):
https://play.golang.org/p/93CBCcMh5g Note that you still have a data race on access to the map. And probably need a way to gracefully shutdown the whole thing. Cheers, Alex On Friday, 20 January 2017 17:10:48 UTC-5, l...@pinkfroot.com wrote: > > Yeah I did try with it enabled and it sees nothing. I use it all the > time, it's great!! > > Thing is I can see the race condition in the code, just trying to work out > how to avoid it! > > On Friday, January 20, 2017 at 10:09:05 PM UTC, Val wrote: >> >> Did you try with the race detector enabled? What was the output? >> If not, you really should, and it's super easy to do. >> Any complain from the race detector is a bug that must be fixed, not a >> mere warning. >> >> Cheers >> Val >> >> On Friday, January 20, 2017 at 8:10:42 PM UTC+1, l...@pinkfroot.com >> wrote: >> >> >>> It is kind of a race condition but one that I don't think will be >>> detected by the detector! >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
