On Saturday, October 28, 2017 at 2:59:53 PM UTC-7, John Souvestre wrote:
>
> Ø I don't think it needs to be uniformly fair. It just needs to prevent
> starvation of a channel for infinity. Any proof would have progress covered
> if we pick every channel once in a while, even under a heavily unfair
> weighting. You have to balance out the overhead of rolling a fair dice and
> the speed at which you can select on channels.
>
>
>
> If it were uniformly fair then you couldn’t guarantee picking every
> channel once in a while. Statistically it would be become more and more
> probable, but never 100%.
>
>
>
> Why not just use round-robin? That would guarantee it and it’s a faster
> algorithm, I would think. Also, it would sometimes save checking all cases
> since you could check them in order, stopping when (if) you found one ready.
>
>
>
> Are there situations where it is better for it to be random or is there
> some implementation advantage (not having to save state for the select)?
>
>
>
Round robin isn't implementable. There's no place to store the state for
an individual select. And you can't store the state in the G (goroutine)
or M (os thread) because then:
for {
select {
case <-x:
case <-y:
}
select {
case <-y:
case <-x:
}
}
would never read from y (or x, depending on the initial state).
I'm not sure how you would even define round robin. What's the unit that's
being round-robined? An individual select statement across all
goroutines? A select statement and goroutine pair? A select statement +
function instance pair?
(The last one is actually implementable - but then select statements behave
differently if you wrap them in a function.)
John
>
> John Souvestre - New Orleans LA
>
--
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.
