(Go language) Network polling and IO mechanism for Go

This is a creation in Article, where the information may have evolved or changed.

Original articles, reproduced please specify the Source: Server non-amateur research-sunface

Brief introduction

This article describes the run-time system of Go-the network I/O section.

Blocking

In the go language, all I/O is blocked, so we have to stick to the idea of writing the go system: Don't write blocking interface and code, and then handle concurrency through goroutines and channels instead of callbacks and futures. One example is the HTTP server in the "Net/http" package, whenever the HTTP server receives a connection, it creates a new goroutine to handle all requests from the connection, so we can write very clear code: What to do first, and then what to do. Unfortunately, however, the blocking I/O provided by the operating system is not suitable for building our own blocking I/O interfaces (interface).

In my previous article on the Go runtime, one of the articles described how the Go Scheduler handles system calls. in order to handle a blocking system call, we need an operating system thread, so if we want to build our own blocking I/O layer on top of the OS's I/O layer, we need to generate a new thread for each Goroutine client connection because the connections are blocked when they execute system calls. Building our own blocking I/O layers when you have 10,000 client threads can become extremely expensive, because these clients block waiting for I/O operations to succeed on their own system calls.

Here, go solves this problem by using the asynchronous interface provided by the OS (Epoll, etc.), but blocks those goroutines that are performing I/O.

Network Polling (Netpoller)The asynchronous I/O to block I/O is done through a network polling (netpoller) section, Netpoller in its own thread, receiving messages from Goroutines that are ready for network I/O. Netpoller uses the interface provided by the operator interface to provide polling for the network sockets. On a Linux system, this interface is Epoll, which is kqueue in BSDs and Darwin and Iocompletionport in Windows. What these interfaces have in common is that they provide a very efficient way to poll the network IO State for user space.
Whenever you open or accept a connection in a go program, the file descriptor behind the connection is set to non-blocking mode. If you try to use the connection for I/O when the file descriptor is not ready, you will return an error that cannot be I/O. When a goroutine attempt to read or write to a connection, if you do not receive the above error, then perform this operation, otherwise call Netpoller, when can perform I/O, let Netpoller notify Goroutine, The Goroutine is then dispatched from the running thread to wait for notification.
When the operating system notifies Netpoller that it can run I/O on a file descriptor, it checks the internal data structure to see if any goroutines are blocking the file, and if so, notifies the Goroutines, These goroutines will then retry the I/O operation that caused it to block before.
If you think the previous introduction was using the Select and poll methods in the old UNIX system, congratulations, the basic guess is right. But Go's Netpoller query is can be dispatched goroutine instead of those function pointers, including the various state variables of the struct, so you do not have to manage these states, and do not have to re-examine the function pointers, these are your traditional UNIX network I/O need to worry about the problem , not required in go.