The reason why using select instead ok-comma is because I don't one upstream to block another. Using blocking ok-comma is ok when upstreams are fast. However, when one is slow, others could starve.
On Friday, July 14, 2017 at 12:46:27 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Jul 13, 2017 at 9:15 PM, Chifeng Chou <cfc...@gmail.com > <javascript:>> wrote: > > > > I implemented a weighted fair queue using a naive approach which is > giving > > different amount of attempts according to weights to access upstreams. > > However, when calls of fetch() come very fast, our internal sync > constructs > > are not ready(when select) and many attempts are simply wasted. > > It seems that Go's scheduler steps in, therefore the results of many > > scenarios are not always predictable. > > > > The involvement of Go's scheduler seems unavoidable. So is it innately > unfit > > to implement WFQ in this way? > > I don't understand why you are using a select statement with a default > case. > > Just use the comma-ok form to read from the channel, as in > https://play.golang.org/p/OqK0nELGcX . > > Ian > -- 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.
