Talking about why Epoll is efficient from I/O multiplexing

In the previous article, I talked about some basic concepts of network programming. In the real use, the most used is I/O multiplexing, is nothing more than select,poll,epoll

Many people refer to the Internet as saying epoll that epoll efficiency is the highest. In fact, it is biased. Epoll is efficient, but it is how to be efficient, it is better than Select or poll excellent where?

We simply analyze it by invoking the process.

First Take select as an example (poll), and look at its invocation process

1. Select the socket you want to work with, and add the interface Fd_set (FD, &set) to the set;

2. Call Select (Max+1, &set,,..)

3. Call Fd_isset (Fd,&set) on all sockets in the set to see if an event occurs on the FD

Problems with Select

1. There is a maximum limit on the number of file descriptors that a single process can monitor, usually 1024, but of course the number can be changed, but since select uses polling for file descriptors, the higher the number of file descriptors, the poorer the performance; (in the Linux kernel header file, there is a definition: #define __ Fd_setsize 1024)
2. Kernel/user space memory copy problem, select need to copy a large number of handle data structure, generating huge overhead;
3. Select returns an array with the entire handle, and the application needs to traverse the entire array to discover which handles have events;
4. Select is triggered horizontally, and if the application does not complete an IO operation on an already-ready file descriptor, then each select call will then notify the process of the file descriptor.

Epoll Call procedure

1. Epoll_create Create a Epoll object, general EPOLLFD = Epoll_create ()

2. Epoll_ctl (Epoll_add/epoll_del) to add/Remove an event of one stream to the Epoll object

such as Epoll_ctl (EPOLLFD, Epoll_ctl_add, Socket, epollin);//Register buffer non-empty event, there is data inflow

Epoll_ctl (EPOLLFD, Epoll_ctl_del, Socket, epollout);//register buffer not full event, that is, the stream can be written

When adding an event, it is actually registering a callback function with the kernel. The callback function is that when an event occurs on the corresponding socket, it is added to the time-ready list of the Epoll object, which is done in the kernel.

3 epoll_wait (EPOLLFD,...), gets the ready event. That is, remove all events from the Ready Events list.

You can see that epoll is more efficient than select in that it returns all of the sockets that have occurred, without needing to be in the user state to determine if there are any events occurring on each socket like select.

Also, when you call Select, the kernel needs to go to one by one to detect if there are events in the incoming socket collection, and when calling Epoll_wait, only the ready data in the kernel is taken out.

If there are n connections, and there are events for all n connections, there is really not much difference between using select and Epoll. For select, the user state is valid for each socket's event monitoring.

But the problem with select is that the socket set is reset every time the select is called. If the number of connections is large, each time Fd_set (FD, &set) invokes the interface, it will also have a significant performance impact. In Epoll, you only need to call the Epoll_ctl once.

Therefore, when the number of connections is very large, and the active connection is not much, the use of epoll has obvious advantages, and if the number of connections are small, and the connection is basically active, in fact, the effect of select is better.

Talking about why Epoll is efficient from I/O multiplexing