broadcasting on a set of channels

[Sunil S Nandihalli]

Hello Everybody,

 I would like to know if there is a way to set up one to many channels.. i.e. Can I have a channel which would broadcast its input on a bunch of channels? The solution I currently use is have a goroutine which listens on this channel and broadcasts it on a collection of channels . If I want to another channel which should be broadcasted on.. then I would add this extra channel to the collection of channels. Is this a good of doing this kind of broadcast? Is there a better way of doing this?

Thanks,

Sunil.

[Rob 'Commander' Pike]

That's how to do it.

-rob

[siddarth shankar]

If the data is only going to be read, could broadcasting pointers
instead of values save some memory alloc/gc depending on subscriber-
size/data-size/broadcast-frequency?
Is this style discouraged?

[Ian Lance Taylor]

siddarth shankar <sith.dart...@gmail.com> writes:

> If the data is only going to be read, could broadcasting pointers
> instead of values save some memory alloc/gc depending on subscriber-
> size/data-size/broadcast-frequency?
> Is this style discouraged?

Sending pointers on a channel is fine. Whether it makes sense depends
on the size of the value, as you say. It would be pointless to send a
pointer rather than an int. It might well be more efficient to send a
pointer rather than a 100-byte structure.

Ian

[Abhishek Kulkarni]

On Fri, Apr 8, 2011 at 2:20 AM, Sunil S Nandihalli <sunil.na...@gmail.com> wrote:

Hello Everybody,

 I would like to know if there is a way to set up one to many channels.. i.e. Can I have a channel which would broadcast its input on a bunch of channels? The solution I currently use is have a goroutine which listens on this channel and broadcasts it on a collection of channels . If I want to another channel which should be broadcasted on.. then I would add this extra channel to the collection of channels. Is this a good of doing this kind of broadcast? Is there a better way of doing this?

roger peppe has a neat "concurrent pearl" on his blog (http://bit.ly/dGP5yj) that you might want to take a look at.

 

Thanks,

Sunil.

[John Asmuth]

I think we should call them "nuts" instead of "pearls".

:)

[siddarth shankar]

Thanks Ian.
Guess I hit enter before including the rationale for the
question.. :-|

The reason I asked if it is discouraged is because of the absence of a
const-style type-constraint.

In that case there won't be an error thrown if the code on the
subscriber-side modifies the data passed as a pointer(library design
for instance)
Could the compiler do this optimization if it knows that the data sent
is not modified?
This could help the GC a lot..
Or would that lead to too much automagic-code/over-engineering?

-- sid

[Ian Lance Taylor]

siddarth shankar <sith.dart...@gmail.com> writes:

> The reason I asked if it is discouraged is because of the absence of a
> const-style type-constraint.
>
> In that case there won't be an error thrown if the code on the
> subscriber-side modifies the data passed as a pointer(library design
> for instance)

That is true.

> Could the compiler do this optimization if it knows that the data sent
> is not modified?
> This could help the GC a lot..
> Or would that lead to too much automagic-code/over-engineering?

The compiler could do that in principle in some cases, but I think the
context would be so limited that it's unlikely that this optimization
would ever be implemented. It could only be done if all the relevant
code were in the same package. The compiler would have to be able to
prove that it could see all possible sends and receives on the channel
in question. Without thinking about it too hard, I suspect that there
would be many cases where it would seem that the optimization would
apply but where the compiler could not quite prove that it would apply.

Ian

[inte...@gmail.com]

Late reply, but still trying to figure something out here.

What happens if the channel closes?

I'm thinking about maintaining a list of channels (one for each websocket client), then sending a message to all of them.  The only problem is that when the websocket client disconnects, their channel closes.  Being there no easy way to skip closed channels, the program crashes. 

[Ian Lance Taylor]

On Tue, Jun 14, 2016 at 10:15 PM, <inte...@gmail.com> wrote:
>
> What happens if the channel closes?
>
> I'm thinking about maintaining a list of channels (one for each websocket
> client), then sending a message to all of them. The only problem is that
> when the websocket client disconnects, their channel closes. Being there no
> easy way to skip closed channels, the program crashes.

To be clear, I assume that we are talking about the Go chan type.

Closing a channel is a send operation, and only the sender should
close a channel. So I'm not sure what you mean when you that when the
websocket client disconnects, their channel closes. If you are
sending a message to the client, then the client should not close the
channel.

Ian

[Eric Greer]

Thanks for the reply. What I'm trying to do is to make a web socket server where all clients are sent broadcast messages. When the client connects, a channel is creates and registered in a global list of client channels. When a client disconnects, the channel gets closed. The broadcaster does not know and crashes.

Is it possible to gracefully skip channels that are closed, or do I need to create a registry of clients that have their own IDs mapped to a channel so that I can prune them?  I ended up doing it this way and I realize that leaving closed channels in the list is memory bloat over time, but it would have saved a lot of time on this throw away program to just loop over a slice of channels.

Thanks again for the reply.

[Ian Lance Taylor]

On Wed, Jun 15, 2016 at 12:25 PM, Eric Greer <inte...@gmail.com> wrote:
>
> Thanks for the reply. What I'm trying to do is to make a web socket server
> where all clients are sent broadcast messages. When the client connects, a
> channel is creates and registered in a global list of client channels. When
> a client disconnects, the channel gets closed. The broadcaster does not know
> and crashes.
>
> Is it possible to gracefully skip channels that are closed, or do I need to
> create a registry of clients that have their own IDs mapped to a channel so
> that I can prune them? I ended up doing it this way and I realize that
> leaving closed channels in the list is memory bloat over time, but it would
> have saved a lot of time on this throw away program to just loop over a
> slice of channels.

Closing a channel is a send operation. It's not closing a file or a
network connection. It's not necessary to close a channel. The only
reason to do so is to send a signal: that there will be no more data
on the channel. For the receiver of a channel to close it is wrong.

You should keep the registry you mention, and at the point where today
you close the channel, you should instead remove the channel from the
registry.

Ian

[Eric Greer]

Perfect. Thanks!

[Øyvind Teig]

occam pi has/had mobile channels, where data pointed to by the pointer that's implicitly sent over the channel will fall out of scope in the sender side. I don't even think that data is converted to a const, the data won't exist anymore. The language takes care of this.

Sending a pointer across without such a mechanism is rather risky, isn't it - of one doesn't introduce a "taken" return message and all parties respect it. If not, is it avoidable to insert data state and eventual polling? 

Øyvind