> I don't believe the actual use case described can be mapped. From what I
> understand, the intended behavior was
> a) put the goroutine to sleep until some communication can proceed
> b) if exactly one communication can proceed, do it
> c) if multiple communications can proceed, choose the one with the highest
> priority
How about:
select {
case <-priorityHigh:
...
default:
select {
case <-priorityLow:
...
default:
select {
case <- priorityHigh:
...
case <- priorityLow:
...
case <- priorityLowest:
...
}
}
}
John
John Souvestre - New Orleans LA
From: 'Axel Wagner' via golang-nuts [mailto:[email protected]]
Sent: 2017 January 25, Wed 10:00
To: Egon
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
I don't believe the actual use case described can be mapped. From what I
understand, the intended behavior was
a) put the goroutine to sleep until some communication can proceed
b) if exactly one communication can proceed, do it
c) if multiple communications can proceed, choose the one with the highest
priority
The suggested solutions (or any I can think of) violate at least one of these.
They either wait busily, violating a, or they try to communicate in
priority-order, then, as a last resort, block on any particular case, violating
b, or they fall back to a regular select, violating c.
I don't know enough about how select is implemented to pass any judgement on
whether this can be efficiently implemented, but I'm also not sure it's such a
great idea. Choosing a case uniformly at random was a deliberate design
decision to prevent starvation. There is a certain danger in people not
realizing that they become susceptible to starvation if they do this. It's also
a feature rabbit-hole
<https://commandcenter.blogspot.ch/2012/06/less-is-exponentially-more.html> .
I'd predict, that next up, someone who experiences starvation wants to add
weighted scheduling ("give this case an 80% chance of succeeding and this other
case 20%, so that eventually either will proceed") or more complicated
scheduling strategies.
I think such edge-cases for scheduling requirements should rather be
implemented separately in a library. Yes, it's complicated code, but that's all
the more reason why it shouldn't be in everyone's go runtime.
On Wed, Jan 25, 2017 at 4:23 PM, Egon <[email protected]> wrote:
On Wednesday, 25 January 2017 15:14:27 UTC+2, T L wrote:
sometimes, I do want one case on a select block get selected even if there are
multiple unblocked cases.
For example, I don't want the dataCh case is selected if the stopCh and the
timer channel are unblocked:
select {
case <- stopCh:
return
case value := <-dataCh:
}
select {
case <- time.After(time.Second):
return
case dataCh <- value:
}
Is there a solution to satisfy my need currently?
type poller func() bool
var pollers []poller
pollers = append(pollers, func() bool {
select {
case <-priority:
// ...
default:
return false
}
return true
})
for {
for _, p := range pollers {
if p() {
break
}
}
}
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
