Skip to content

Commit

Permalink
GitBook: [#21] No subject
Browse files Browse the repository at this point in the history
  • Loading branch information
@webxiaohua @gitbook-bot
webxiaohua authored and gitbook-bot committed Dec 29, 2021
1 parent cd13c41 commit fa3c3e4
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions 5.-ni-guan-zhe-po-wan-yi-jiao-io-duo-lu-fu-yong.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ read(buff);

但是这里我们忽略了一个问题，那就是虽然我们执行了往哪里写数据，但是我们该从哪里读数据呢？ 从上一节中我们知道，通过文件这个概念我们能实现几乎所有I/O操作，**因此这里少的一个主角就是文件**。 

那么我们一般都这么使用文件呢？
那么我们一般都怎么使用文件呢？

![](.gitbook/assets/5\_2.jpg)

Expand Down Expand Up @@ -104,7 +104,7 @@ if(read(socket_fd2, buff) > 0) {

那么这个问题该怎么解决呢？ 

**这里的关键点在于在进行I/O时，我们并不是到该文件描述对于的I/O设备是否是可读的、是否是可写的**，在外设的不可读或不可写的状态下进行I/O只会导致进程阻塞被暂停运行。 
**这里的关键点在于在进行I/O时，我们并不知道该文件描述对于的I/O设备是否是可读的、是否是可写的**，在外设的不可读或不可写的状态下进行I/O只会导致进程阻塞被暂停运行。 

因此要优雅的解决这个问题，就要从其它角度来思考这个问题了。

Expand All @@ -122,7 +122,7 @@ if(read(socket_fd2, buff) > 0) {

现在你应该明白了吧，处理多个文件描述符的更好方法其实就存在于推销电话中。 

因此相比上一节中我们主动通过I/O接口主动问内核这些文件描述符对应的外设是不是已经就绪了，一种更好的方法是，我们把这些内核一股脑扔给内核，并霸气的告诉内核：“我这里有1万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理”。而不是弱弱的问内核：“第一个文件描述可以读写了吗？第二个文件描述符可以读写吗？第三个文件描述符可以读写了 吗？” 
因此相比上一节中我们通过I/O接口主动问内核这些文件描述符对应的外设是不是已经就绪了，一种更好的方法是，我们把这些内核一股脑扔给内核，并霸气的告诉内核：“我这里有1万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理”。而不是弱弱的问内核：“第一个文件描述可以读写了吗？第二个文件描述符可以读写吗？第三个文件描述符可以读写了吗？” 

这样应用程序就从“繁忙”的主动变为清闲的被动了，反正哪些设备ok了内核会通知我， 能偷懒我才不要那么勤奋。

Expand All @@ -140,7 +140,7 @@ multiplexing一词其实多用于通信领域，为了充分利用通信线路

所谓I/O多路复用指的是这样一个过程：

1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可 以) 
1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以) 
2. 通过调用**某个函数**告诉内核：“**这个函数你先不要返回，你替我监视着这些描述符，当这堆文件描述符中有可以进行I/O读写操作的时候你再返回**”
3. 当调用的这个函数返回后我们就能知道哪些文件描述符可以进行I/O操作了。

Expand Down Expand Up @@ -170,7 +170,7 @@ multiplexing一词其实多用于通信领域，为了充分利用通信线路
* 用户给我的文件描述符需要拷贝的内核中
* 我只能告诉你有文件描述符满足要求了，但是我不知道是哪个，你自己一个一个去找吧(遍历)

因此我们可以看到，select机制的特性在高性能网络服务器动辄几万几十万并发链接的场景下无疑是 低效的。
因此我们可以看到，select机制的特性在高性能网络服务器动辄几万几十万并发链接的场景下无疑是低效的。

![](.gitbook/assets/5\_9.jpg)

Expand All @@ -194,7 +194,7 @@ poll和select是非常相似的，poll相对于select的优化仅仅在于解决

![](.gitbook/assets/5\_10.jpg)

在这种机制下，进程不需要亲自下场了，进程只要等待在epoll上，epoll代替进程去各个文件描述符 上等待，当哪个文件描述符可读或者可写的时候就告诉epoll，epoll用小本本认真记录下来然后唤醒 大哥：“进程大哥，快醒醒，你要处理的文件描述符我都记下来了”，这样进程被唤醒后就无需自己从 头到尾检查一遍，因为epoll都已经记下来了。 
在这种机制下，进程不需要亲自下场了，进程只要等待在epoll上，epoll代替进程去各个文件描述符 上等待，当哪个文件描述符可读或者可写的时候就告诉epoll，epoll用小本本认真记录下来然后唤醒大哥：“进程大哥，快醒醒，你要处理的文件描述符我都记下来了”，这样进程被唤醒后就无需自己从 头到尾检查一遍，因为epoll都已经记下来了。 

因此我们可以看到，在这种机制下，实际上利用的就是“不要打电话给我，有需要我会打给你”，这就 不需要一遍一遍像孙子一样问各个文件描述符了，而是翻身做主人当大爷了，“你们那个文件描述符 可读或者可写了主动报上来”，这中机制实际上就是大名鼎鼎的事件驱动，event-driven，这也是我们 下一篇的主题。 

Expand Down

0 comments on commit fa3c3e4

Please sign in to comment.