Linux Select, Poll and Epoll difference

1. select
2. poll
3. epoll

select

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

Select is currently supported on almost all platforms, and its good cross-platform support is also one of its advantages. In fact, from the present point of view, this is also one of its few remaining advantages.

A 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 on Linux, but this limit can be increased by modifying the macro definition or even recompiling the kernel.

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

poll

poll was born in System V Release 3 in 1986. It is not much different from select in essence, but poll has no limit on the maximum number of file descriptors.

The same disadvantage of poll and select is that the array containing a large number of file descriptors is copied between the user mode and the kernel address space as a whole, regardless of whether these file descriptors are ready or not, its overhead increases with the number of file descriptors while increasing linearly.

In addition, after select() and poll() tell the process the ready file descriptors, if the process does not perform IO operations on them, these file descriptors will be reported again the next time select() and poll() are called, so They generally do not lose ready messages, which is called Level Triggered. 

epoll

It was not until Linux2.6 that the implementation method directly supported by the kernel appeared, that is, epoll, which has almost all the advantages mentioned above and is recognized as the best multi-channel I/O ready notification method under Linux2.6.

epoll can support both horizontal triggering and edge triggering (Edge Triggered, only tells the process which file descriptors have just become ready, it only says once, if we don't take action, then it will not be notified again, this method is called Edge triggering), in theory, the performance of edge triggering is higher, but the code implementation is quite complicated.

epoll also only informs those ready file descriptors, and when we call epoll_wait() to get ready file descriptors, what is returned is not the actual descriptor, but a value representing the number of ready descriptors, you only need to go to epoll to specify It is enough to obtain the corresponding number of file descriptors in an array in turn, and the memory mapping (mmap) technology is also used here, which completely saves the overhead of copying these file descriptors during system calls.

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

Continuing...