Linux file io (quad) IO multiplexing

When the program is IO, the IO is blocked if the data is not ready. When a process has multiple open files, such as a socket, then all files that are ready to be read and written will be affected by blocking and cannot be manipulated. Without threading, a single process cannot serve multiple file descriptors at the same time. Non-blocking IO can be used as a solution, but not very efficient. First the process needs to constantly send IO requests, and secondly, if the program can hibernate, the CPU will increase efficiency. Multitasking IO is notified when any one of the file descriptors is ready and the IO is not blocked, the rest of the time is dormant, and the CPU resources are given to other processes.
The design of I/O multiplexing follows these guidelines:
1,I/O multiplexing: Tell me when any file descriptor is ready for I/O
2, always sleep before one or more file descriptors are ready.
3, Wake up: which is ready?
4, handle all I/O-ready file descriptors without blocking.
5, return to the first step and start over again.

There are three kinds of multitasking IO: Select, poll and Epoll.
Select monitors a large file descriptor, which is monitored by the largest file descriptor Maxfd plus 1, and divides the monitored file descriptors into three groups, which can be manipulated by Fd_isset macros to see which FD corresponding bitmap becomes ready. Because select () is easy to implement in a variety of UNIX systems, the Select () is often used as a portable microsecond sleep mechanism with respect to microsecond-precision sleep Mechanisms: Select (0, NULL, NULL, NULL, &TV). In addition BSD is the first pselect () system call. Select can be used in a scenario where the number of file descriptors is relatively determined.
The poll is a System V IO multiplexing scheme that uses a POLLFD array to set file descriptors that need to be monitored, which is more efficient than a select needs to check maxfd+1 bits for each packet.

Epoll interface
Epoll the listener registration from the actual monitoring to isolate, thereby solving the problem. One system call Initializes a Epoll context, the other adds or removes the file descriptor that needs to be monitored from the context, and the third performs a true event wait (eventwait). If the events item in the EPOLL_CTL () parameter event is set to EPOLLE,FD on the listener is called an edge trigger, the opposite is called a horizontal trigger. For a level-triggered listener, the call to Epoll_wait () in step 2 returns immediately to indicate that the pipe is readable. For edge-triggered snooping, this call is not returned until step 1 occurs. That is, even if the pipeline is already readable when calling epoll_wait (), the call will still wait until there is data to write, and then return. The horizontal trigger is the default behavior. It is also the behavior of poll () and select (), which is what most developers expect. Edge triggering requires a different way of writing the program, usually using non-blocking I/O and needing to examine the eagain carefully.
A horizontal trigger is triggered when a state occurs. Edge triggering occurs only when the state changes. Horizontal triggering is useful when you are only concerned about the state. Edge triggering is useful when you care about the event itself.

Epoll is an enhanced version of the multiplexed IO interface select/poll for Linux, which significantly increases the CPU utilization of the program in the presence of a small number of active concurrent connections. Because it does not reuse the set of file descriptors to pass the results, forcing the developer to prepare a collection of file descriptors to be listened to before each wait for the event, the other reason is that it does not have to traverse the entire set of descriptors to be listened to when the event is acquired. Just walk through the set of descriptors that are joined to the ready queue by a kernel IO event that wakes up asynchronously. Epoll provides edge triggering (edge triggered) in addition to the level triggered of Select/poll IO events, which makes it possible for user space programs to cache IO status and reduce epoll_wait/ Epoll_pwait calls to improve application efficiency. The main advantages of Epoll are:
1, support a process to open a large number of socket descriptors;
2, IO efficiency does not decrease linearly with the increase of FD number;
3. Use Mmap to accelerate the message delivery of the kernel and user space.
int epoll_create (int size)
Epoll_create () Creates an Epoll instance that returns the file descriptor associated with the instance. This file descriptor is not related to a real file, but is created only for subsequent calls using Epoll.

int epoll_ctl (int epfd, int op, int fd, struct epoll_event *event);
Adds an FD specified listener parameter in the EPFD instance to the event that the OP is used to add, delete, and modify the FD specified file. The events parameter in the events structure lists the event that is listening on the given file descriptor. Multiple events can be specified at the same time using a bitwise OR operation. The most common is listening to read and write events: Epollin | Epollout.

int epoll_wait (int epfd, struct epoll_event events, int maxevents, int timeout);
The return value is the number of events and an error returns-1. Events to ensure that there is enough buffer:
Events = malloc (sizeof (struct epoll_event) max_events);
nr_events = epoll_wait (EPFD, events, max_events,-1);
If timeout is 0, the call returns immediately, even if no event occurs, at which time the call returns 0. If timeout is-1, the call waits until an event occurs.

Linux file io (quad) IO multiplexing