auto commit
This commit is contained in:
CyC2018
parent
4b9c46a2c7
commit
8d0e24361e
|
|
@ -55,17 +55,13 @@
|
|||
* [十、I/O 复用](#十io-复用)
|
||||
* [概念理解](#概念理解)
|
||||
* [I/O 模型](#io-模型)
|
||||
* [select() poll() epoll](#select-poll-epoll)
|
||||
* [select poll epoll](#select-poll-epoll)
|
||||
* [select 和 poll 比较](#select-和-poll-比较)
|
||||
<<<<<<< HEAD
|
||||
* [eopll 工作模式](#eopll-工作模式)
|
||||
* [select poll epoll 应用场景](#select-poll-epoll-应用场景)
|
||||
* [2. poll 应用场景](#2-poll-应用场景)
|
||||
* [3. epoll 应用场景](#3-epoll-应用场景)
|
||||
* [4. 性能对比](#4-性能对比)
|
||||
=======
|
||||
* [select() poll() epoll 应用场景](#select-poll-epoll-应用场景)
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
|
|
@ -1155,28 +1151,20 @@ I/O Multiplexing 又被称为 Event Driven I/O，它可以让单个进程具有
|
|||
|
||||
<div align="center"> <img src="../pics//b4b29aa9-dd2c-467b-b75f-ca6541cb25b5.jpg"/> </div><br>
|
||||
|
||||
## select() poll() epoll
|
||||
## select poll epoll
|
||||
|
||||
这三个都是 I/O 多路复用的具体实现，select 出现的最早，之后是 poll，再是 epoll。可以说，新出现的实现是为了修复旧实现的不足。
|
||||
|
||||
假如做一个Web服务器没有 I/O 多路复用，就需要为每一个客户端连接创建一个线程去处理。而负载均衡，可能同时连接几万个连接，那就需要创建几万个线程处理客户端请求啊？显然不是的，应该使用 I/O 多路复用，也就是一个线程同时处理多个 I/O 请求，epoll 可以由一个线程同时处理上百万个 socket 连接。
|
||||
|
||||
### 1. select()
|
||||
### 1. select
|
||||
|
||||
```c
|
||||
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
|
||||
```
|
||||
|
||||
- fd_set 表示描述符集合；
|
||||
<<<<<<< HEAD
|
||||
- readset、writeset 和 exceptset 这三个参数指定让操作系统内核测试读、写和异常条件的描述符；
|
||||
- timeout 参数告知内核等待所指定描述符中的任何一个就绪可花多少时间；
|
||||
- 成功调用返回结果大于 0；出错返回结果为 -1；超时返回结果为 0。
|
||||
=======
|
||||
- readset、writeset 和 exceptset 这三个参数指定让内核测试读、写和异常条件的描述符；
|
||||
- timeout 参数告知内核等待所指定描述符中的任何一个就绪可花多少时间。
|
||||
- return 成功调用返回结果大于0；出错返回结果为-1；超时返回结果为0
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
|
||||
```c
|
||||
fd_set fd_in, fd_out;
|
||||
|
|
@ -1217,15 +1205,9 @@ else
|
|||
}
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
每次调用 select() 都需要将 fd_set \*readfds, fd_set \*writefds, fd_set \*exceptfds 链表内容全部从用户进程内存中复制到操作系统内核中，内核需要将所有 fd_set 遍历一遍，这个过程非常低效。
|
||||
|
||||
每次调用 select() 都需要将 fd_set \*readfds, fd_set \*writefds, fd_set \*exceptfds 链表内容全部从用户进程内存中复制到 OS 内核中，内核需要将所有 fd_set 遍历一遍，这个过程非常低效。
|
||||
=======
|
||||
每次调用 select() 都需要将 `fd_set *readfds, fd_set *writefds, fd_set *exceptfds` 链表内容全部从用户进程内存中复制到OS内核中，内核需要将所有 fd_set 遍历一遍，这个过程非常低效。
|
||||
|
||||
返回结果中内核并没有声明哪些 fd_set 已经准备好了，所以如果返回值大于0时，程序需要遍历所有的 fd_set 判断哪个 I/O 已经准备好。
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
|
||||
在 Linux 中 select 最多支持 1024 个 fd_set 同时轮询，其中 1024 由 Linux 内核的 FD_SETSIZE 决定。如果需要打破该限制可以修改 FD_SETSIZE，然后重新编译内核。
|
||||
|
||||
|
|
@ -1275,11 +1257,7 @@ else
|
|||
}
|
||||
```
|
||||
|
||||
<<<<<<< HEAD
|
||||
它和 select() 功能基本相同。同样需要每次将 struct pollfd \*fds 复制到内核，返回后同样需要进行轮询每一个 pollfd 是否已经 I/O 准备好。poll() 取消了 1024 个描述符数量上限，但是数量太大以后不能保证执行效率，因为复制大量内存到内核十分低效，所需时间与描述符数量成正比。poll() 在 pollfd 的重复利用上比 select() 的 fd_set 会更好。
|
||||
=======
|
||||
它和 select() 功能基本相同。同样需要每次将 `struct pollfd *fds` 复制到内核，返回后同样需要进行轮询每一个 pollfd 是否已经 I/O 准备好。poll() 取消了 1024 个描述符数量上限，但是数量太大以后不能保证执行效率，因为复制大量内存到内核十分低效，所需时间与描述符数量成正比。poll() 在 pollfd 的重复利用上比 select() 的 fd_set 会更好。
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
|
||||
如果在多线程下，如果一个线程对某个描述符调用了 poll() 系统调用，但是另一个线程关闭了该描述符，会导致 poll() 调用结果不确定，该问题同样出现在 select() 中。
|
||||
|
||||
|
|
@ -1340,23 +1318,10 @@ else
|
|||
|
||||
epoll 仅仅适用于 Linux OS。
|
||||
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
它是 select() 和 poll() 的增强版，更加灵活而且没有描述符限制。它将用户关心的描述符放到内核的一个事件表中，从而只需要在用户空间和内核空间拷贝一次。
|
||||
|
||||
新版本的 `epoll_create(int size)` 参数 size 不起任何作用，在旧版本的 epoll 中如果描述符的数量大于 size，不保证服务质量。
|
||||
|
||||
epoll_ctl 执行一次系统调用，用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理。
|
||||
|
||||
epoll_wait 取出在内核中通过链表维护的 I/O 准备好的描述符，将他们从内核复制到程序中，不需要像 select() poll() 对注册的所有描述符遍历一遍。
|
||||
|
||||
epoll 对多线程编程更有友好，同时多个线程对同一个描述符调用了 epoll_wait 也不会产生像 select() poll() 的不确定情况。或者一个线程调用了 epoll_wait 另一个线程关闭了同一个描述符也不会产生不确定情况。
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
它是 select 和 poll 的增强版，更加灵活而且没有描述符限制。它将用户关心的描述符放到内核的一个事件表中，从而只需要在用户空间和内核空间拷贝一次。
|
||||
|
||||
select 和 poll 方式中，进程只有在调用一定的方法后，内核才对所有监视的描述符进行扫描。而 epoll 事先通过 epoll_ctl() 来注册描述符，一旦基于某个描述符就绪时，内核会采用类似 callback 的回调机制，迅速激活这个描述符，当进程调用 epoll_wait() 时便得到通知。
|
||||
|
||||
<<<<<<< HEAD
|
||||
新版本的 epoll_create(int size) 参数 size 不起任何作用，在旧版本的 epoll 中如果描述符的数量大于 size，不保证服务质量。
|
||||
|
||||
epoll_ct() 执行一次系统调用，用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理。
|
||||
|
|
@ -1364,16 +1329,6 @@ epoll_ct() 执行一次系统调用，用于向内核注册新的描述符或者
|
|||
epoll_wait() 取出在内核中通过链表维护的 I/O 准备好的描述符，将他们从内核复制到程序中，不需要像 select/poll 对注册的所有描述符遍历一遍。
|
||||
|
||||
epoll 对多线程编程更有友好，同时多个线程对同一个描述符调用了 epoll_wait 也不会产生像 select/poll 的不确定情况。或者一个线程调用了 epoll_wait 另一个线程关闭了同一个描述符也不会产生不确定情况。
|
||||
=======
|
||||
#### eopll 工作模式
|
||||
|
||||
epoll 对文件描述符的操作有两种模式：LT（level trigger）和 ET（edge trigger）。
|
||||
|
||||
epoll_event有两种触发模式，LT模式和ET模式
|
||||
|
||||
- LT 模式：当 epoll_wait() 检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用 epoll_wait() 时，会再次响应应用程序并通知此事件。是默认的一种模式，并且同时支持 Blocking 和 No-Blocking。
|
||||
- ET 模式：当 epoll_wait() 检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用 epoll_wait() 时，不会再次响应应用程序并通知此事件。很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。只支持 No-Blocking，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
|
||||
## select 和 poll 比较
|
||||
|
||||
|
|
@ -1396,9 +1351,8 @@ poll 和 select 在速度上都很慢。
|
|||
|
||||
几乎所有的系统都支持 select，但是只有比较新的系统支持 poll。
|
||||
|
||||
## select() poll() epoll 应用场景
|
||||
## eopll 工作模式
|
||||
|
||||
<<<<<<< HEAD
|
||||
epoll_event 有两种触发模式：LT（level trigger）和 ET（edge trigger）。
|
||||
|
||||
### 1. LT 模式
|
||||
|
|
@ -1434,29 +1388,6 @@ poll 没有最大描述符数量的限制，如果平台支持应该采用 poll
|
|||
## 4. 性能对比
|
||||
|
||||
> [epoll Scalability Web Page](http://lse.sourceforge.net/epoll/index.html)
|
||||
=======
|
||||
很容易产生一种错觉认为只要用 epoll() 就可以了，select() poll() 都是历史遗留问题，并没有什么应用场景，其实并不是这样的。
|
||||
|
||||
### select() 应用场景
|
||||
|
||||
select() poll() epoll_wait() 都有一个 timeout 参数，在 select() 中 timeout 的精确度为 1ns，而 poll() 和 epoll_wait() 中则为 1ms,。所以 select 更加适用于实时要求更高的场景，比如核反应堆的控制。
|
||||
|
||||
select 历史更加悠久，它的可移植性更好，几乎被所有主流平台所支持。
|
||||
|
||||
### poll() 应用场景
|
||||
|
||||
poll 没有最大描述符数量的限制，如果平台支持应该采用 poll 且对实时性要求并不是十分严格，而不是 select。
|
||||
|
||||
需要同时监控小于 1000 个描述符。那么也没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。
|
||||
|
||||
需要监控的描述符状态变化多，而且都是非常短暂的。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。epoll 的描述符存储在内核，不容易调试。
|
||||
|
||||
### epoll 应用场景
|
||||
|
||||
程序只需要运行在 Linux 平台上，且、有非常大量的描述符需要同时轮询，比如一万，且这些连接最好是长连接。
|
||||
|
||||
[poll 与 epoll 的性能对比](http://lse.sourceforge.net/epoll/index.html)
|
||||
>>>>>>> 682cb5dc73dc0c4ddce34e00e305bdb7ccbaef5e
|
||||
|
||||
# 参考资料
|
||||
|
||||
|
|
@ -1465,7 +1396,6 @@ poll 没有最大描述符数量的限制，如果平台支持应该采用 poll
|
|||
- [Boost application performance using asynchronous I/O](https://www.ibm.com/developerworks/linux/library/l-async/)
|
||||
- [Synchronous and Asynchronous I/O](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx)
|
||||
- [Linux IO 模式及 select、poll、epoll 详解](https://segmentfault.com/a/1190000003063859)
|
||||
- [select / poll / epoll: practical difference for system architects](https://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/)
|
||||
- [poll vs select vs event-based](https://daniel.haxx.se/docs/poll-vs-select.html)
|
||||
- [Linux 之守护进程、僵死进程与孤儿进程](http://liubigbin.github.io/2016/03/11/Linux-%E4%B9%8B%E5%AE%88%E6%8A%A4%E8%BF%9B%E7%A8%8B%E3%80%81%E5%83%B5%E6%AD%BB%E8%BF%9B%E7%A8%8B%E4%B8%8E%E5%AD%A4%E5%84%BF%E8%BF%9B%E7%A8%8B/)
|
||||
- [Linux process states](https://idea.popcount.org/2012-12-11-linux-process-states/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user