On Wed, 13 Mar 2019 at 23:01, Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> 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.
