Last active
January 21, 2023 18:27
-
-
Save robbiev/1854d3fc9dcb7ae884423e39f93dc1e7 to your computer and use it in GitHub Desktop.
select with priority in go
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// SOLUTION 1 | |
// see https://groups.google.com/forum/#!topic/golang-nuts/ChPxr_h8kUM | |
func maybe(b bool, c chan int) chan int { | |
if !b { | |
return nil | |
} | |
return c | |
} | |
select { | |
case <-maybe(val>0, p): | |
val-- | |
case <-v: | |
val++ | |
} | |
// SOLUTION 2 | |
// see https://groups.google.com/forum/#!topic/golang-nuts/M2xjN_yWBiQ | |
select { | |
case <-higher: | |
foo() | |
default: | |
select { | |
case <-lower: | |
bar() | |
default: | |
... | |
} | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@kent-h
I'm not sure we're talking about the same problem so let's make sure of that first. I think the problem is: In a stream of events that might have gaps where there are no events, process higher priority events before processing lower priority events. Do not spin the CPU when there are no events.
Neither your code nor @robbiev 's #2 meet that criteria.
The behavior of #2 is:
If we put this code in a loop, it would spin the CPU when there were no events to read.
The behavior of your code is:
If we put your code in a loop, then it would only give preference to higher if there were higher waiting in the queue. That is a much weaker guarantee that what my code provides.