Select, poll, and epoll

Address: http://blog.endlesscode.com/2010/03/27/select-poll-epoll-intro/by Stephen posted
On 2010/03/27

I do not know much about select, poll, and epoll. The following is an introduction from building a high-performance web site, and so on.

Select

Select first appeared in. It monitors arrays of multiple file descriptors through a select () system call. When select () returns, the ready file descriptor in the array will be modified by the kernel so that the process can obtain these file descriptors for subsequent read/write operations.

Currently, select supports almost all platforms, and its good cross-platform support is also an advantage. In fact, this is also one of its few advantages.

One disadvantage of select is that there is a maximum limit on the number of file descriptors that a single process can monitor, which is generally 1024 in Linux, however, this restriction can be improved by modifying the macro definition or re-compiling the kernel.

In addition, the data structure maintained by select () stores a large number of file descriptors. As the number of file descriptors increases, the overhead of copying also increases linearly. At the same time, due to the delay in network response time, a large number of TCP connections are inactive, but calling select () will perform a linear scan on all sockets, which also wastes a certain amount of overhead.

Poll

Poll was born in System V Release 3 in 1986. It is essentially no different from select, But poll has no limit on the maximum number of file descriptors.

Poll and select have the same disadvantage: An array containing a large number of file descriptors is copied between the user State and the kernel address space, regardless of whether these file descriptors are ready, its overhead increases linearly with the increase in the number of file descriptors.

In addition, after select () and Poll () Tell the process the ready file descriptor, if the process does not perform Io operations on it, the next call of select () and Poll () these file descriptors are reported again, so they generally do not lose the ready message. This method is called level triggered ).

Epoll

It wasn't until linux2.6 that there was an implementation method directly supported by the kernel, namely epoll, which had almost all the advantages mentioned earlier, it is recognized that linux2.6 has the best performance in multi-channel I/O ready notification methods.

Epoll supports both horizontal triggering and edge triggering (edge triggered). It only tells the process which file descriptors have just changed to the ready state. If we do not take any action, so it will not tell you again that this method is called edge triggering). Theoretically, edge triggering has a higher performance, but the code implementation is quite complicated.

Epoll also only informs the ready file descriptors. When we call epoll_wait () to obtain the ready file descriptor, the returned value is not the actual descriptor, but a value representing the number of ready descriptors, you only need to obtain the corresponding number of file descriptors in sequence in an array specified by epoll. The memory ing (MMAP) technology is also used here, this completely saves the overhead of copying these file descriptors during system calls.

Another essential improvement is that epoll uses event-based readiness notification. In select/poll, the kernel scans all monitored file descriptors only after a certain method is called, and epoll registers a file descriptor through epoll_ctl () in advance, once a file descriptor is ready, the kernel uses a callback mechanism similar to callback to quickly activate the file descriptor. When the process calls epoll_wait (), it is notified.