When goroutine blocks I / O, how does the scheduler identify that it has stopped the block?

Question

From what I read here , the golang scheduler will automatically detect if goroutine is blocked on I / O and will automatically switch to handle other goroutines in a thread that is not blocked.

I am wondering how the scheduler then finds out that this goroutine has stopped the I / O lock.

Does he just do some kind of poll so often to check if everything is blocked? Is there some kind of background thread that checks the status of all goroutines?

---

For example, if you want to execute an HTTP GET request inside goroutine, which took 5 seconds to get a response, it will block waiting for a response, and the scheduler will switch to processing another goroutine. Now, considering that when the server returns the answer, how does the scheduler understand that the answer has arrived and it is time to return to the goroutine that made the GET so that it can process the GET result?

Answer 1

All input / output operations must be performed using system calls, and the methods of switching to system calls in Go, they are always called through code that is controlled by the runtime. This means that when you call syscall, and not just call it directly (thereby denying control of the thread in the kernel), the runtime is notified of which Syscall you want to do, and it does it on behalf of goroutine. This allows, for example, to execute a non-blocking syscall instead of blocking (in essence, the kernel), please do it, but instead of blocking it before it completes, return immediately and let me know later, as soon as the result is ready "). This allows him to continue to do other work in the meantime.