select on slice of channels

619 views
Skip to first unread message

Andrey Tcherepanov

unread,
Sep 13, 2019, 12:40:29 AM9/13/19
to golang-nuts
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

unread,
Sep 13, 2019, 2:02:18 AM9/13/19
to Andrey Tcherepanov, golang-nuts
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

unread,
Sep 13, 2019, 6:22:16 AM9/13/19
to Ian Lance Taylor, Andrey Tcherepanov, golang-nuts
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

unread,
Sep 13, 2019, 11:59:58 AM9/13/19
to golang-nuts
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

unread,
Sep 13, 2019, 2:09:26 PM9/13/19
to Andrey Tcherepanov, golang-nuts
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

unread,
Sep 14, 2019, 9:45:46 AM9/14/19
to golang-nuts
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.


Reply all
Reply to author
Forward
0 new messages