select on slice of channels

[Andrey Tcherepanov]

Folks,

well, subj - why can't I "just"  do a select on a slice of channels? Yes, I can run a bunch goroutines with of reads on an each channel, funnel it all into 1 notification channel, pick up on the other side...  boring stuff, really... 

But why not  "just" 

func main() {

    cc := make([]chan interface{}, 10)

    for i := 0; i < len(cc); i++ {
        cc[i] = make(chan interface{})
    }

    dd := make([]chan int)

    for i := 0; i < 1000; i++ {
        dd = append(dd, make(chan int))
    }
 
 select {

   // do we need a special <-[] ?
   case i, c, v, ok := <-[]cc:
      fmt.Printf("cc replied : channel index %d, channel %v, value %v, ok=%v", i, c, v, ok)


   // or I dunno, not introducing a new op
   case i, d, v, ok := <-dd:
      fmt.Printf("dd sent something: channel index %d, channel %v, value %v, ok=%v", i, d, v, ok)
 }
 
 // or shorter, but I hope you get the drift
 
 select {
   case i, c, ok := <-[]cc:
      fmt.Printf("cc replied : channel index %d, channel %v, value %v, ok=%v", i, c, <-c, ok)


   case i, d, ok := <-dd:
      fmt.Printf("dd sent something: channel index %d, channel %v, value %v, ok=%v", i, d, <-d, ok)
 }
}

Why? System limitations? Rarely needed?

Feels like extending language to handle that would not be too much of violation of an existing code. Ok, lets go nuts! Mirrored "cc <- value" for sending to a slice of channels! -- it should pick randomly available channel out of the slice of channels!

[Ian Lance Taylor]

You actually can do it using the reflect package:
https://golang.org/pkg/reflect/#Select (not because we necessarily
want the reflect package to support selecting on a slice of channels,
but because there is no other reasonable way to write reflect.Select).

It's not in the language proper mainly because it doesn't seem to come
up very much. I don't think there is even a proposal for it. And
while anyone is welcome to write a proposal, it will need some
justification for why it will be worth the cost of complicating the
language.

Ian

[Rob Pike]

The feature was in Newsqueak but we deliberately omitted it from Go because the cost of the operation can be very high and we weren't comfortable provided such concise notation for such an expensive operation.

-rob

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX51e7RpZJwco%2BPwFc_kWU7EsQ_3kFWYL9basO5gGyc9A%40mail.gmail.com.

[Andrey Tcherepanov]

Thanks Ian,

it is nice to know that there is at least "an escape hatch" through reflect package if needed.

Is there an upper bound for how many items could be in that slice (select statement)? 

Andrey

[Ian Lance Taylor]

On Fri, Sep 13, 2019 at 9:00 AM Andrey Tcherepanov
<xnow4f...@sneakemail.com> wrote:
>
> it is nice to know that there is at least "an escape hatch" through reflect package if needed.
>
> Is there an upper bound for how many items could be in that slice (select statement)?

Not really. At some point if you keep adding cases you'll run out of memory.

Ian

[Nate Finch]

You're better off funnelling everything into a single channel.

There's little real difference between reading from one channel that N things write to, and reading from N channels that have one writer each.