I am currently dealing with a race related bug, at least, I found a bug, and it coincided with a race when I enabled the race detector, and the bug is a deadlock, and the shared shut-down button clearly can be pressed on and off in the wrong order.
So my first strategy in fixing the bug is putting channel mutexes around the read/write operations.However, I'm not sure it's the most efficient solution. Basically it's two variables, which have related functions (quit and a cursor) so I think I can cover them with one lock. The quit lock will be infrequently accessed so I think it doesn't affect performance when it's actually meant to be working. As regards to closing channels, this is always about only doing that in one place. Unless closing the channel is itself the signal, there should only be one open and one close function and usually in the same scope, possibly even with a defer to be safe it is closed in a panic and when the system it is part of can be reinitialised and restarted. As I understand it, closing channels is mostly used as a quit signal, so there is usually only sender and many receivers, you can't get a race inside a serial thread. This doubles the utility of the channel that is being used to pass data around between processes, in that you can configure this signal for quit or reload or pause or whatever toggle/pushbutton type switch you want to have, with the addition of a response that reopens the channel after it closes, to act like a 'my turn' signal. But more usually that would just be done by having several workers listening for work, and only one sender, or one broker, or other consensus. There's more than a few layers to the interlock between this and others of the go maxims, sharing a sender and receiver channel at the same time is a bad idea, in general. You either are funnelling concurrent processes into a serial process, or fanning a serial stream out into concurrent processes. The close is cognate to the nil in that it is not zero but it is not a number either, so in some situations you can use it as a message in itself. On Thursday, 14 March 2019 13:51:29 UTC+1, rog wrote: > > On Wed, 13 Mar 2019 at 23:01, Andrey Tcherepanov <xnow4f...@sneakemail.com > <javascript:>> wrote: > >> There were couple of things I was implementing for our little in-house >> server app. >> One was (in)famous fan-out pattern for broadcasting messages to clients, >> and one for job queue(s) that could run fast (seconds) or long (hours, >> days) where items kind of coming it from multiple (same) clients. >> > > I'd be interested to hear a little more about these tasks. There are many > possible design choices there. For example, if one client is slow to read > its messages, what strategy would you choose? You could discard messages, > amalgamate messages, slow messages to other clients, etc. The choice you > make can have significant impact on the design of your system. > > FWIW the usual convention is to avoid sharing the memory that contains the > channel. The same channel can be stored in two places - both refer to the > same underlying channel. So when the sender goes away, it can nil its own > channel without interfering with the receiver's channel. > > cheers, > rog. > -- 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.
