3 ms·
I understand that network polling is only performed then. For network IO in general things look different: E.g. if you do a write() the runtime will first try t
by Matthias247 9y ago
I understand that network polling is only performed then. For network IO in general things look different: E.g. if you do a write() the runtime will first try to perform it synchronously in a nonblocking fashion. Only when that fails (E_WOULDBLOCK) then the executing goroutine is parked until the network poller executes and gets the information that IO is possible again.
- omginternets 9y agoSo if I had GOMAXPROCS set to 1 and had two goroutines, one doing file IO and one doing var i int for { i++ } the former goroutine would never actually perform the IO? (I can't fight the feeling that I'm misunderstanding this on some level...)
- echlebek 9y agoYes. The goroutine that increments i in a loop never has a chance to yield to the scheduler. package main import ( "fmt" "time" ) func main() { go func() { time.Sleep(100 * time.Millisecond) fmt.Println("hi") }() var i int for { i++ } } $ GOMAXPROCS=1 go run test.go # never prints anything
- Matthias247 9y agoHowever that should happen only in a loop without function calls inside it. Afaik the newer Go versions will also yield in the function call preambles to the scheduler from time to time to give another goroutine in ready state the chance to run.
- echlebek 9y agoThat's right. The newer releases of Go include more points where goroutines will yield to the scheduler. I'm unsure about how that plays with inlining, though.