Last active
March 21, 2017 19:14
Star
You must be signed in to star a gist
Experiment to see if saturating the goroutine worker pool with long-running tasks delays goroutines that are queued later
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
// This is a test to get a better understanding of Go's scheduling. | |
// The hypothesis is that if the goroutine worker pool is saturated with | |
// long-running tasks, then a goroutine that is queued later will not be | |
// scheduled until the long-running tasks complete. | |
// | |
// Tested in Go 1.7 using this command: | |
// | |
// go build -gcflags '-N -l' blocker.go && ./blocker | |
// | |
// The `gcflags` setting is my attempt to disable inlining, to give | |
// blocked goroutines a chance to be pre-empted on function entry. | |
// | |
package main | |
import ( | |
"fmt" | |
"runtime" | |
"sync" | |
"time" | |
) | |
func blocker(wg *sync.WaitGroup) { | |
for { | |
doStuff() | |
} | |
fmt.Println("blocker done") | |
wg.Done() | |
} | |
func doStuff() int { | |
return 1 | |
} | |
func outputter(wg *sync.WaitGroup) { | |
fmt.Println("done") | |
wg.Done() | |
} | |
func main() { | |
runtime.GOMAXPROCS(3) | |
var wg sync.WaitGroup | |
wg.Add(4) | |
for i := 0; i < 3; i++ { | |
go blocker(&wg) | |
} | |
time.Sleep(1 * time.Second) | |
go outputter(&wg) | |
wg.Wait() | |
fmt.Println("exit") | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment