Let's say you make a sudoku solver, as fast as possible.
You have a multicore computer.
If the disk read or parsing is slow, you are going to prepare sudoku files
in 3 goroutines, let's say.
And the 4th thread (the main thread, let's say) will solve them.
How the main thread can get sudoku to solve from the goroutines ?
Of course, the channel let you send each sudoku from the reader goroutines
to the main thread. But :
2 bad possibilities :
1- You read a goroutine. But it's blocking and maybe another is ready
faster. You can't check.
2- You read all of them in a no-blocking way, constantly checking all of
them. It's a hell-loop, consuming a lot of CPU.
Here is the power of select.
You just do this :
for {
select {
case sudoku <- chanReaderA:
solve(sudoku)
case sudoku <- chanReaderB:
solve(sudoku)
case sudoku <- chanReaderC:
solve(sudoku)
}
}
}
What happens ?
The select "pauses" your program, listening to all those 3 channels. It
waits for a message.
When a message come, it launch the corresponding instruction. Here, always
the same instruction : "solve(sudoku)"
It's not only about performance : It's readable and short.
Le jeudi 19 janvier 2017 18:33:38 UTC+1, John C. a écrit :
>
> On several occasions the Go designers have alluded to the fact that the
> 'select' mechanism and the fact that it's built in to the language are very
> important for concurrency (can't seem to find references). While I
> understand just fine how to use select/goroutines/channels, the overarching
> importance of select as a built-in feature is escaping me.
>
> Can somebody help me see the big "why" picture better?
>
> Thanks,
> John C.
>
>
--
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.
