Merge pull request #4 from sterchelen/patch-1

guide: fix typo on gorouting scheduler section
This commit is contained in:
Felix Geisendörfer 2021-09-11 15:40:15 +02:00 committed by GitHub
commit 9bddcf1855
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -46,7 +46,7 @@ Here we have a single goroutine, let's call it `G1`, that runs the `main` functi
<img src="./timeline.png" width=600/> <img src="./timeline.png" width=600/>
From the scheduler's perspective, the program above executes like shown below. At first `G1` is `Executing` on `CPU 1`. Then the goroutine is taken off the CPU while `Waiting` for the network. Once the scheduler notices that the network has replied (using non-blocking I/O, similar to to Node.js), it marks the goroutine as `Runnable`. And as soon as a CPU core becomes available, the goroutine starts `Executing` again. In our case all cores are available, so `G1` can go back to `Executing` the `fmt.Printf()` function on one of the CPUs immediately without spending any time in the `Runnable` state. From the scheduler's perspective, the program above executes like shown below. At first `G1` is `Executing` on `CPU 1`. Then the goroutine is taken off the CPU while `Waiting` for the network. Once the scheduler notices that the network has replied (using non-blocking I/O, similar to Node.js), it marks the goroutine as `Runnable`. And as soon as a CPU core becomes available, the goroutine starts `Executing` again. In our case all cores are available, so `G1` can go back to `Executing` the `fmt.Printf()` function on one of the CPUs immediately without spending any time in the `Runnable` state.
<img src="./scheduler.gif" width=400/> <img src="./scheduler.gif" width=400/>