In https://play.golang.org/p/fqPXXpNufO you need to protect all channelMap access with a mutex, in https://play.golang.org/p/88zT7hBLeD you don't. If you make it a package-level var, `make` it in `init` or check if it is nil before you `make` in jobDispatcher, as you should assume you have no control over how many times jobDispatcher will be called.
Your working example (https://play.golang.org/p/88zT7hBLeD) shouldn't deadlock. It panics because the processing cannot keep up with the message generation. Try this, slightly modified version, and see that a short break allows it to catch up: https://play.golang.org/p/ysszy7WDcG (btw, I increased the sleep time in checkingFunctionThatBlocks, to trigger the condition faster). Also, that code seems unnecessarily convoluted to me. What guarantees do you need to provide for processing the packets? For example, right now, you seem concerned about out-of-order packets, yet you discard any packets older than 5 seconds, whether they were processed or not. And what is the nature of the "checking": are you looking for some kind of "signal" packet, or are you trying to reconstitute messages from a sequence of incoming packets? Cheers, Alex On Saturday, 21 January 2017 09:45:10 UTC-5, l...@pinkfroot.com wrote: > > I just uploaded a working example to https://play.golang.org/p/88zT7hBLeD > > It is a long running process so will need running locally on a machine as > the playground kills it. Hopefully this will help get to the bottom of it! > > Lee > > On Saturday, January 21, 2017 at 8:24:04 AM UTC, l...@pinkfroot.com wrote: >> >> Thanks Alex, >> >> I did what I would call a halfway house so to speak... >> >> https://play.golang.org/p/fqPXXpNufO >> >> It ran for much longer before locking on the same line! Trouble is, now >> I can't actually see the lock whereas I could before! >> >> I'm wondering if I should keep a global channelMap and lock that with >> sync.RWMutex and whether that may help? >> >> Lee >> >> On Saturday, January 21, 2017 at 3:01:08 AM UTC, Alex Bucataru wrote: >>> >>> 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.
