does Go allow recving from an array of channels?

[yigong liu]

Hello,

In Limbo, the receive operator "<-" can receive from an array of channels. Does Go support this?

Thanks

YGL

[Rob 'Commander' Pike]

No. It's a fine feature for some languages but at large scale it
becomes very expensive so we decided to leave it out of Go. It's not
too hard to write an O(1) multiplexer in Go; array select is O(N).

-rob

[Ben Tilly]

With a tree of goroutines you could do array select in O(log(N)) even
without having it built in.

Of course the lack of generics means you'd have to reimplement this
for every kind of channel you wanted...

Ben

[Russ Cox]

>> No.  It's a fine feature for some languages but at large scale it becomes
>> very expensive so we decided to leave it out of Go.  It's not too hard to
>> write an O(1) multiplexer in Go; array select is O(N).
>
> With a tree of goroutines you could do array select in O(log(N)) even
> without having it built in.

No, you can do it in O(1), like the mail you quoted says.

> Of course the lack of generics means you'd have to reimplement this
> for every kind of channel you wanted...

Thanks for your input.
Russ

[Ben Tilly]

On Mon, Nov 16, 2009 at 8:27 PM, Russ Cox <r...@golang.org> wrote:
>>> No.  It's a fine feature for some languages but at large scale it becomes
>>> very expensive so we decided to leave it out of Go.  It's not too hard to
>>> write an O(1) multiplexer in Go; array select is O(N).
>>
>> With a tree of goroutines you could do array select in O(log(N)) even
>> without having it built in.
>
> No, you can do it in O(1), like the mail you quoted says.

I may be missing something here.

My reading of http://golang.org/doc/go_spec.html#Select_statements
suggests that you can do a O(1) select of any number of channels, but
the specific channels you are selecting on has to be hard coded in
your program because you need explicit case statements in your code
for the list of possibilities.

To handle a list of channels whose size is dynamic at runtime takes
more work. The approach I thought of is to set up a tree of
goroutines that multiplex off of each other. You can then write a
function that takes in a slice of channels which sets up this tree and
returns a channel that returns pairs of (channel_index, value) each
time it is read.

Is there another possibility that I missed?

>> Of course the lack of generics means you'd have to reimplement this
>> for every kind of channel you wanted...
>
> Thanks for your input.

Thanks for your language! Trying to figure out how it does things and
how I could do things with it has been fun and educational. Hopefully
some day what I am learning will be useful for me.

Cheers,
Ben

[Russ Cox]

> Is there another possibility that I missed?

It is okay for a channel to have many writers.
In this case I think you can just have N goroutines
each reading from a specific channel and writing
to a shared channel. The main goroutine just reads
the one channel.

Russ

[Ben Tilly]

D'oh. That is obviously the right design.

In another thread I saw that you can box any type you want to type
interface {}, and then you can unbox it back to whatever type you
want. If you try to unbox a value to a type it isn't, then you get a
panic.

At the cost of that unboxing (and possible run-time crashes the type
system can't catch at compile time) I can see how to implement this
design entirely generically without having generics in the language.

Thanks,
Ben