This is the seventh day of my participation in the August More text Challenge. For details, see:August is more challenging
The select/poll/epoll contrast:
Note: The traversal is equivalent to looking at all locations, and the callback is equivalent to looking at the corresponding location.
1 select
POSIX, which is currently supported on almost all platforms, also has good cross-platform support, essentially by setting or checking the data structure that holds the FD flag bit for further processing
disadvantages
- The number of FDS that can be monitored by a single process is limited, that is, the number of ports that can be monitored is limited, and this value is stored in the following files:
cat /proc/sys/fs/file-max - The socket is scanned linearly, that is, the polling method is used, and the efficiency is low
- Select adopts the memory copy method to realize that the kernel notifies the user space of the FD message. Such a data structure is used to store a large number of FDS, which makes the replication cost of the user space and the kernel space when passing the structure
Select is the first version of I/O reuse, raised after the leak a lot of problems.
- Select modifies the array of arguments passed in, which is very unfriendly for a function that needs to be called many times
- If data is present on any sock(I/O stream), select will only return data, but will not tell you which sock has data
- Select can only monitor 1024 links
- Select is not thread safe. If you add a sock to select and then suddenly another thread finds that sock is not used, withdraw it
2 poll
Essentially the same as select, it copies the array passed in by the user into kernel space and then queries the device state for each FD
- There is no maximum number of connections because it is stored based on a linked list
- A large number of arrays of FDS are copied collectively between the user mode and the kernel address space, regardless of whether such copying makes sense
- Polls are “horizontally triggered”. If an FD is reported and not processed, it will be reported again in the next poll
- Edge firing: Notifying only once. Epoll uses edge firing
Poll fixes a number of issues with select:
- Poll removes the limit of 1024 links
- Polls by design do not modify incoming arrays
But polling is still not thread-safe, which means that no matter how powerful the server is, you can only handle a set of I/O streams in one thread. Of course you can have multiple processes, but then you have all sorts of problems with multiple processes.
3 epoll
Enhanced versions of select and poll proposed in Linux2.6 kernel
- Supports both horizontal and edge firing. The best feature is edge firing, which only tells the process which FDS have just become ready, and only once
- Using an “event” ready notification, register a fd with epoll_CTL, and once the FD is ready, the kernel activates the FD using a callback like a callback, and epoll_WAIT is notified
advantages
- – There is no maximum concurrent connection limit: the maximum number of FDS that can be opened is much higher than 1024(1G of memory listens on about 100,000 ports)
- Improved efficiency: in the non-polling mode, the efficiency does not decrease as the number of FDS increases; The best thing about epoll is that it only manages “active” connections, not the total number of connections
- Memory copy, using mmap() file mapping memory to accelerate message passing with kernel space; That is, epoll uses MMAP to reduce replication overhead
- File mapped memory is accessed directly through the address space, which is more efficient and maps files to memory
Epoll is the latest implementation of I/O multiplexing. It fixes most of the problems with poll and SELECT, such as:
- Epoll is now thread safe
- Epoll now not only tells you which sock group has the data, it also tells you which sock has the data, so you don’t have to find it yourself
- In epoll mode, all file descriptors are stored in kernel mode, so you don’t need to pass file descriptors into the query