python之路——IO模型

IO模型介紹

　　為了更好地了解IO模型，我們需要事先回顧下：同步、異步、阻塞、非阻塞

? ??同步（synchronous） IO和異步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什么，到底有什么區(qū)別？這個(gè)問題其實(shí)不同的人給出的答案都可能不同，比如wiki，就認(rèn)為asynchronous IO和non-blocking IO是一個(gè)東西。這其實(shí)是因?yàn)椴煌娜说闹R背景不同，并且在討論這個(gè)問題的時(shí)候上下文(context)也不相同。所以，為了更好的回答這個(gè)問題，我先限定一下本文的上下文。

??? 本文討論的背景是Linux環(huán)境下的network IO。本文最重要的參考文獻(xiàn)是Richard Stevens的“UNIX? Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2節(jié)“I/O Models ”，Stevens在這節(jié)中詳細(xì)說明了各種IO的特點(diǎn)和區(qū)別，如果英文夠好的話，推薦直接閱讀。Stevens的文風(fēng)是有名的深入淺出，所以不用擔(dān)心看不懂。本文中的流程圖也是截取自參考文獻(xiàn)。

? ? Stevens在文章中一共比較了五種IO Model：

??? * blocking IO? ? ? ? ? ?阻塞IO

??? * nonblocking IO? ? ? 非阻塞IO

??? * IO multiplexing? ? ? IO多路復(fù)用

??? * signal driven IO? ? ?信號驅(qū)動IO

??? * asynchronous IO? ? 異步IO

??? 由signal driven IO（信號驅(qū)動IO）在實(shí)際中并不常用，所以主要介紹其余四種IO Model。

? ? 再說一下IO發(fā)生時(shí)涉及的對象和步驟。對于一個(gè)network IO (這里我們以read舉例)，它會涉及到兩個(gè)系統(tǒng)對象，一個(gè)是調(diào)用這個(gè)IO的process (or thread)，另一個(gè)就是系統(tǒng)內(nèi)核(kernel)。當(dāng)一個(gè)read操作發(fā)生時(shí)，該操作會經(jīng)歷兩個(gè)階段：

#1）等待數(shù)據(jù)準(zhǔn)備 (Waiting for the data to be ready)

#2）將數(shù)據(jù)從內(nèi)核拷貝到進(jìn)程中(Copying the data from the kernel to the process)

　　記住這兩點(diǎn)很重要，因?yàn)檫@些IO模型的區(qū)別就是在兩個(gè)階段上各有不同的情況。

阻塞IO(blocking IO)

　　在linux中，默認(rèn)情況下所有的socket都是blocking，一個(gè)典型的讀操作流程大概是這樣：

　　當(dāng)用戶進(jìn)程調(diào)用了recvfrom這個(gè)系統(tǒng)調(diào)用，kernel就開始了IO的第一個(gè)階段：準(zhǔn)備數(shù)據(jù)。對于network io來說，很多時(shí)候數(shù)據(jù)在一開始還沒有到達(dá)（比如，還沒有收到一個(gè)完整的UDP包），這個(gè)時(shí)候kernel就要等待足夠的數(shù)據(jù)到來。

? ? 而在用戶進(jìn)程這邊，整個(gè)進(jìn)程會被阻塞。當(dāng)kernel一直等到數(shù)據(jù)準(zhǔn)備好了，它就會將數(shù)據(jù)從kernel中拷貝到用戶內(nèi)存，然后kernel返回結(jié)果，用戶進(jìn)程才解除block的狀態(tài)，重新運(yùn)行起來。

????所以，blocking IO的特點(diǎn)就是在IO執(zhí)行的兩個(gè)階段（等待數(shù)據(jù)和拷貝數(shù)據(jù)兩個(gè)階段）都被block了。

? ? 幾乎所有的程序員第一次接觸到的網(wǎng)絡(luò)編程都是從listen()、send()、recv() 等接口開始的，使用這些接口可以很方便的構(gòu)建服務(wù)器/客戶機(jī)的模型。然而大部分的socket接口都是阻塞型的。如下圖

? ? ps：所謂阻塞型接口是指系統(tǒng)調(diào)用（一般是IO接口）不返回調(diào)用結(jié)果并讓當(dāng)前線程一直阻塞，只有當(dāng)該系統(tǒng)調(diào)用獲得結(jié)果或者超時(shí)出錯(cuò)時(shí)才返回。

　　實(shí)際上，除非特別指定，幾乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。這給網(wǎng)絡(luò)編程帶來了一個(gè)很大的問題，如在調(diào)用recv(1024)的同時(shí)，線程將被阻塞，在此期間，線程將無法執(zhí)行任何運(yùn)算或響應(yīng)任何的網(wǎng)絡(luò)請求。

? ? 一個(gè)簡單的解決方案：

#在服務(wù)器端使用多線程（或多進(jìn)程）。多線程（或多進(jìn)程）的目的是讓每個(gè)連接都擁有獨(dú)立的線程（或進(jìn)程），這樣任何一個(gè)連接的阻塞都不會影響其他的連接。

? ? 該方案的問題是：

#開啟多進(jìn)程或都線程的方式，在遇到要同時(shí)響應(yīng)成百上千路的連接請求，則無論多線程還是多進(jìn)程都會嚴(yán)重占據(jù)系統(tǒng)資源，降低系統(tǒng)對外界響應(yīng)效率，而且線程與進(jìn)程本身也更容易進(jìn)入假死狀態(tài)。

? ? 改進(jìn)方案： ? ?

#很多程序員可能會考慮使用“線程池”或“連接池”?！熬€程池”旨在減少創(chuàng)建和銷毀線程的頻率，其維持一定合理數(shù)量的線程，并讓空閑的線程重新承擔(dān)新的執(zhí)行任務(wù)?！斑B接池”維持連接的緩存池，盡量重用已有的連接、減少創(chuàng)建和關(guān)閉連接的頻率。這兩種技術(shù)都可以很好的降低系統(tǒng)開銷，都被廣泛應(yīng)用很多大型系統(tǒng)，如websphere、tomcat和各種數(shù)據(jù)庫等。

? ? 改進(jìn)后方案其實(shí)也存在著問題：

#“線程池”和“連接池”技術(shù)也只是在一定程度上緩解了頻繁調(diào)用IO接口帶來的資源占用。而且，所謂“池”始終有其上限，當(dāng)請求大大超過上限時(shí)，“池”構(gòu)成的系統(tǒng)對外界的響應(yīng)并不比沒有池的時(shí)候效果好多少。所以使用“池”必須考慮其面臨的響應(yīng)規(guī)模，并根據(jù)響應(yīng)規(guī)模調(diào)整“池”的大小。

??? 對應(yīng)上例中的所面臨的可能同時(shí)出現(xiàn)的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。總之，多線程模型可以方便高效的解決小規(guī)模的服務(wù)請求，但面對大規(guī)模的服務(wù)請求，多線程模型也會遇到瓶頸，可以用非阻塞接口來嘗試解決這個(gè)問題。

非阻塞IO(non-blocking IO)

Linux下，可以通過設(shè)置socket使其變?yōu)閚on-blocking。當(dāng)對一個(gè)non-blocking socket執(zhí)行讀操作時(shí)，流程是這個(gè)樣子：

　　從圖中可以看出，當(dāng)用戶進(jìn)程發(fā)出read操作時(shí)，如果kernel中的數(shù)據(jù)還沒有準(zhǔn)備好，那么它并不會block用戶進(jìn)程，而是立刻返回一個(gè)error。從用戶進(jìn)程角度講 ，它發(fā)起一個(gè)read操作后，并不需要等待，而是馬上就得到了一個(gè)結(jié)果。用戶進(jìn)程判斷結(jié)果是一個(gè)error時(shí)，它就知道數(shù)據(jù)還沒有準(zhǔn)備好，于是用戶就可以在本次到下次再發(fā)起read詢問的時(shí)間間隔內(nèi)做其他事情，或者直接再次發(fā)送read操作。一旦kernel中的數(shù)據(jù)準(zhǔn)備好了，并且又再次收到了用戶進(jìn)程的system call，那么它馬上就將數(shù)據(jù)拷貝到了用戶內(nèi)存（這一階段仍然是阻塞的），然后返回。

? ? 也就是說非阻塞的recvform系統(tǒng)調(diào)用調(diào)用之后，進(jìn)程并沒有被阻塞，內(nèi)核馬上返回給進(jìn)程，如果數(shù)據(jù)還沒準(zhǔn)備好，此時(shí)會返回一個(gè)error。進(jìn)程在返回之后，可以干點(diǎn)別的事情，然后再發(fā)起recvform系統(tǒng)調(diào)用。重復(fù)上面的過程，循環(huán)往復(fù)的進(jìn)行recvform系統(tǒng)調(diào)用。這個(gè)過程通常被稱之為輪詢。輪詢檢查內(nèi)核數(shù)據(jù)，直到數(shù)據(jù)準(zhǔn)備好，再拷貝數(shù)據(jù)到進(jìn)程，進(jìn)行數(shù)據(jù)處理。需要注意，拷貝數(shù)據(jù)整個(gè)過程，進(jìn)程仍然是屬于阻塞的狀態(tài)。

? ? 所以，在非阻塞式IO中，用戶進(jìn)程其實(shí)是需要不斷的主動詢問kernel數(shù)據(jù)準(zhǔn)備好了沒有。

?非阻塞IO實(shí)例

但是非阻塞IO模型絕不被推薦。

? ? 我們不能否則其優(yōu)點(diǎn)：能夠在等待任務(wù)完成的時(shí)間里干其他活了（包括提交其他任務(wù)，也就是 “后臺” 可以有多個(gè)任務(wù)在“”同時(shí)“”執(zhí)行）。

? ? 但是也難掩其缺點(diǎn)：

#1. 循環(huán)調(diào)用recv()將大幅度推高CPU占用率；這也是我們在代碼中留一句time.sleep(2)的原因,否則在低配主機(jī)下極容易出現(xiàn)卡機(jī)情況

#2. 任務(wù)完成的響應(yīng)延遲增大了，因?yàn)槊窟^一段時(shí)間才去輪詢一次read操作，而任務(wù)可能在兩次輪詢之間的任意時(shí)間完成。這會導(dǎo)致整體數(shù)據(jù)吞吐量的降低。

? ??此外，在這個(gè)方案中recv()更多的是起到檢測“操作是否完成”的作用，實(shí)際操作系統(tǒng)提供了更為高效的檢測“操作是否完成“作用的接口，例如select()多路復(fù)用模式，可以一次檢測多個(gè)連接是否活躍。

多路復(fù)用IO(IO multiplexing)

　　IO multiplexing這個(gè)詞可能有點(diǎn)陌生，但是如果我說select/epoll，大概就都能明白了。有些地方也稱這種IO方式為事件驅(qū)動IO(event driven IO)。我們都知道，select/epoll的好處就在于單個(gè)process就可以同時(shí)處理多個(gè)網(wǎng)絡(luò)連接的IO。它的基本原理就是select/epoll這個(gè)function會不斷的輪詢所負(fù)責(zé)的所有socket，當(dāng)某個(gè)socket有數(shù)據(jù)到達(dá)了，就通知用戶進(jìn)程。它的流程如圖：

　　當(dāng)用戶進(jìn)程調(diào)用了select，那么整個(gè)進(jìn)程會被block，而同時(shí)，kernel會“監(jiān)視”所有select負(fù)責(zé)的socket，當(dāng)任何一個(gè)socket中的數(shù)據(jù)準(zhǔn)備好了，select就會返回。這個(gè)時(shí)候用戶進(jìn)程再調(diào)用read操作，將數(shù)據(jù)從kernel拷貝到用戶進(jìn)程。

??? 這個(gè)圖和blocking IO的圖其實(shí)并沒有太大的不同，事實(shí)上還更差一些。因?yàn)檫@里需要使用兩個(gè)系統(tǒng)調(diào)用(select和recvfrom)，而blocking IO只調(diào)用了一個(gè)系統(tǒng)調(diào)用(recvfrom)。但是，用select的優(yōu)勢在于它可以同時(shí)處理多個(gè)connection。

? ? 強(qiáng)調(diào)：

? ? 1. 如果處理的連接數(shù)不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優(yōu)勢并不是對于單個(gè)連接能處理得更快，而是在于能處理更多的連接。

? ? 2.?在多路復(fù)用模型中，對于每一個(gè)socket，一般都設(shè)置成為non-blocking，但是，如上圖所示，整個(gè)用戶的process其實(shí)是一直被block的。只不過process是被select這個(gè)函數(shù)block，而不是被socket IO給block。

? ??結(jié)論: select的優(yōu)勢在于可以處理多個(gè)連接，不適用于單個(gè)連接?

#服務(wù)端from socket import *import select

s=socket(AF_INET,SOCK_STREAM)

s.setsockopt(SOL_SOCKET,SO_REUSEADDR,1)

s.bind(('127.0.0.1',8081))

s.listen(5)

s.setblocking(False) #設(shè)置socket的接口為非阻塞read_l=[s,]while True:

? ? r_l,w_l,x_l=select.select(read_l,[],[])

? ? print(r_l)

? ? for ready_obj in r_l:

? ? ? ? if ready_obj == s:

? ? ? ? ? ? conn,addr=ready_obj.accept() #此時(shí)的ready_obj等于s? ? ? ? ? ? read_l.append(conn)

? ? ? ? else:

? ? ? ? ? ? try:

? ? ? ? ? ? ? ? data=ready_obj.recv(1024) #此時(shí)的ready_obj等于conn? ? ? ? ? ? ? ? if not data:

? ? ? ? ? ? ? ? ? ? ready_obj.close()

? ? ? ? ? ? ? ? ? ? read_l.remove(ready_obj)

? ? ? ? ? ? ? ? ? ? continue? ? ? ? ? ? ? ? ready_obj.send(data.upper())

? ? ? ? ? ? except ConnectionResetError:

? ? ? ? ? ? ? ? ready_obj.close()

? ? ? ? ? ? ? ? read_l.remove(ready_obj)#客戶端from socket import *

c=socket(AF_INET,SOCK_STREAM)

c.connect(('127.0.0.1',8081))while True:

? ? msg=input('>>: ')

? ? if not msg:continue? ? c.send(msg.encode('utf-8'))

? ? data=c.recv(1024)

? ? print(data.decode('utf-8'))

?select監(jiān)聽fd變化的過程分析：

#用戶進(jìn)程創(chuàng)建socket對象，拷貝監(jiān)聽的fd到內(nèi)核空間，每一個(gè)fd會對應(yīng)一張系統(tǒng)文件表，內(nèi)核空間的fd響應(yīng)到數(shù)據(jù)后，就會發(fā)送信號給用戶進(jìn)程數(shù)據(jù)已到；

#用戶進(jìn)程再發(fā)送系統(tǒng)調(diào)用，比如（accept）將內(nèi)核空間的數(shù)據(jù)copy到用戶空間，同時(shí)作為接受數(shù)據(jù)端內(nèi)核空間的數(shù)據(jù)清除，這樣重新監(jiān)聽時(shí)fd再有新的數(shù)據(jù)又可以響應(yīng)到了（發(fā)送端因?yàn)榛赥CP協(xié)議所以需要收到應(yīng)答后才會清除）。

? ??該模型的優(yōu)點(diǎn)：

#相比其他模型，使用select() 的事件驅(qū)動模型只用單線程（進(jìn)程）執(zhí)行，占用資源少，不消耗太多 CPU，同時(shí)能夠?yàn)槎嗫蛻舳颂峁┓?wù)。如果試圖建立一個(gè)簡單的事件驅(qū)動的服務(wù)器程序，這個(gè)模型有一定的參考價(jià)值。

? ? 該模型的缺點(diǎn)：

#首先select()接口并不是實(shí)現(xiàn)“事件驅(qū)動”的最好選擇。因?yàn)楫?dāng)需要探測的句柄值較大時(shí)，select()接口本身需要消耗大量時(shí)間去輪詢各個(gè)句柄。

#很多操作系統(tǒng)提供了更為高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。

#如果需要實(shí)現(xiàn)更高效的服務(wù)器程序，類似epoll這樣的接口更被推薦。遺憾的是不同的操作系統(tǒng)特供的epoll接口有很大差異，

#所以使用類似于epoll的接口實(shí)現(xiàn)具有較好跨平臺能力的服務(wù)器會比較困難。

#其次，該模型將事件探測和事件響應(yīng)夾雜在一起，一旦事件響應(yīng)的執(zhí)行體龐大，則對整個(gè)模型是災(zāi)難性的。

異步IO(Asynchronous I/O)

Linux下的asynchronous IO其實(shí)用得不多，從內(nèi)核2.6版本才開始引入。先看一下它的流程：

　　用戶進(jìn)程發(fā)起read操作之后，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當(dāng)它受到一個(gè)asynchronous read之后，首先它會立刻返回，所以不會對用戶進(jìn)程產(chǎn)生任何block。然后，kernel會等待數(shù)據(jù)準(zhǔn)備完成，然后將數(shù)據(jù)拷貝到用戶內(nèi)存，當(dāng)這一切都完成之后，kernel會給用戶進(jìn)程發(fā)送一個(gè)signal，告訴它read操作完成了。

IO模型比較分析

到目前為止，已經(jīng)將四個(gè)IO Model都介紹完了?，F(xiàn)在回過頭來回答最初的那幾個(gè)問題：blocking和non-blocking的區(qū)別在哪，synchronous IO和asynchronous IO的區(qū)別在哪。

? ? 先回答最簡單的這個(gè)：blocking vs non-blocking。前面的介紹中其實(shí)已經(jīng)很明確的說明了這兩者的區(qū)別。調(diào)用blocking IO會一直block住對應(yīng)的進(jìn)程直到操作完成，而non-blocking IO在kernel還準(zhǔn)備數(shù)據(jù)的情況下會立刻返回。

? ? 再說明synchronous IO和asynchronous IO的區(qū)別之前，需要先給出兩者的定義。Stevens給出的定義（其實(shí)是POSIX的定義）是這樣子的：

????A synchronous I/O operation causes the requesting process to be blocked until that?I/O operationcompletes;

??? An asynchronous I/O operation does not cause the requesting process to be blocked;?

? ? 兩者的區(qū)別就在于synchronous IO做”IO operation”的時(shí)候會將process阻塞。按照這個(gè)定義，四個(gè)IO模型可以分為兩大類，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬于synchronous IO這一類，而?asynchronous I/O后一類 。

? ? 有人可能會說，non-blocking IO并沒有被block啊。這里有個(gè)非常“狡猾”的地方，定義中所指的”IO operation”是指真實(shí)的IO操作，就是例子中的recvfrom這個(gè)system call。non-blocking IO在執(zhí)行recvfrom這個(gè)system call的時(shí)候，如果kernel的數(shù)據(jù)沒有準(zhǔn)備好，這時(shí)候不會block進(jìn)程。但是，當(dāng)kernel中數(shù)據(jù)準(zhǔn)備好的時(shí)候，recvfrom會將數(shù)據(jù)從kernel拷貝到用戶內(nèi)存中，這個(gè)時(shí)候進(jìn)程是被block了，在這段時(shí)間內(nèi)，進(jìn)程是被block的。而asynchronous IO則不一樣，當(dāng)進(jìn)程發(fā)起IO 操作之后，就直接返回再也不理睬了，直到kernel發(fā)送一個(gè)信號，告訴進(jìn)程說IO完成。在這整個(gè)過程中，進(jìn)程完全沒有被block。

? ? 各個(gè)IO Model的比較如圖所示：

　　經(jīng)過上面的介紹，會發(fā)現(xiàn)non-blocking IO和asynchronous IO的區(qū)別還是很明顯的。在non-blocking IO中，雖然進(jìn)程大部分時(shí)間都不會被block，但是它仍然要求進(jìn)程去主動的check，并且當(dāng)數(shù)據(jù)準(zhǔn)備完成以后，也需要進(jìn)程主動的再次調(diào)用recvfrom來將數(shù)據(jù)拷貝到用戶內(nèi)存。而asynchronous IO則完全不同。它就像是用戶進(jìn)程將整個(gè)IO操作交給了他人（kernel）完成，然后他人做完后發(fā)信號通知。在此期間，用戶進(jìn)程不需要去檢查IO操作的狀態(tài)，也不需要主動的去拷貝數(shù)據(jù)。

selectors模塊

IO復(fù)用：為了解釋這個(gè)名詞，首先來理解下復(fù)用這個(gè)概念，復(fù)用也就是共用的意思，這樣理解還是有些抽象，為此，咱們來理解下復(fù)用在通信領(lǐng)域的使用，在通信領(lǐng)域中為了充分利用網(wǎng)絡(luò)連接的物理介質(zhì)，往往在同一條網(wǎng)絡(luò)鏈路上采用時(shí)分復(fù)用或頻分復(fù)用的技術(shù)使其在同一鏈路上傳輸多路信號，到這里我們就基本上理解了復(fù)用的含義，即公用某個(gè)“介質(zhì)”來盡可能多的做同一類(性質(zhì))的事，那IO復(fù)用的“介質(zhì)”是什么呢？為此我們首先來看看服務(wù)器編程的模型，客戶端發(fā)來的請求服務(wù)端會產(chǎn)生一個(gè)進(jìn)程來對其進(jìn)行服務(wù)，每當(dāng)來一個(gè)客戶請求就產(chǎn)生一個(gè)進(jìn)程來服務(wù)，然而進(jìn)程不可能無限制的產(chǎn)生，因此為了解決大量客戶端訪問的問題，引入了IO復(fù)用技術(shù)，即：一個(gè)進(jìn)程可以同時(shí)對多個(gè)客戶請求進(jìn)行服務(wù)。也就是說IO復(fù)用的“介質(zhì)”是進(jìn)程(準(zhǔn)確的說復(fù)用的是select和poll，因?yàn)檫M(jìn)程也是靠調(diào)用select和poll來實(shí)現(xiàn)的)，復(fù)用一個(gè)進(jìn)程(select和poll)來對多個(gè)IO進(jìn)行服務(wù)，雖然客戶端發(fā)來的IO是并發(fā)的但是IO所需的讀寫數(shù)據(jù)多數(shù)情況下是沒有準(zhǔn)備好的，因此就可以利用一個(gè)函數(shù)(select和poll)來監(jiān)聽IO所需的這些數(shù)據(jù)的狀態(tài)，一旦IO有數(shù)據(jù)可以進(jìn)行讀寫了，進(jìn)程就來對這樣的IO進(jìn)行服務(wù)。

理解完IO復(fù)用后，我們在來看下實(shí)現(xiàn)IO復(fù)用中的三個(gè)API(select、poll和epoll)的區(qū)別和聯(lián)系

select，poll，epoll都是IO多路復(fù)用的機(jī)制，I/O多路復(fù)用就是通過一種機(jī)制，可以監(jiān)視多個(gè)描述符，一旦某個(gè)描述符就緒（一般是讀就緒或者寫就緒），能夠通知應(yīng)用程序進(jìn)行相應(yīng)的讀寫操作。但select，poll，epoll本質(zhì)上都是同步I/O，因?yàn)樗麄兌夹枰谧x寫事件就緒后自己負(fù)責(zé)進(jìn)行讀寫，也就是說這個(gè)讀寫過程是阻塞的，而異步I/O則無需自己負(fù)責(zé)進(jìn)行讀寫，異步I/O的實(shí)現(xiàn)會負(fù)責(zé)把數(shù)據(jù)從內(nèi)核拷貝到用戶空間。三者的原型如下所示：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

1.select的第一個(gè)參數(shù)nfds為fdset集合中最大描述符值加1，fdset是一個(gè)位數(shù)組，其大小限制為__FD_SETSIZE（1024），位數(shù)組的每一位代表其對應(yīng)的描述符是否需要被檢查。第二三四參數(shù)表示需要關(guān)注讀、寫、錯(cuò)誤事件的文件描述符位數(shù)組，這些參數(shù)既是輸入?yún)?shù)也是輸出參數(shù)，可能會被內(nèi)核修改用于標(biāo)示哪些描述符上發(fā)生了關(guān)注的事件，所以每次調(diào)用select前都需要重新初始化fdset。timeout參數(shù)為超時(shí)時(shí)間，該結(jié)構(gòu)會被內(nèi)核修改，其值為超時(shí)剩余的時(shí)間。

select的調(diào)用步驟如下：

（1）使用copy_from_user從用戶空間拷貝fdset到內(nèi)核空間

（2）注冊回調(diào)函數(shù)__pollwait

（3）遍歷所有fd，調(diào)用其對應(yīng)的poll方法（對于socket，這個(gè)poll方法是sock_poll，sock_poll根據(jù)情況會調(diào)用到tcp_poll,udp_poll或者datagram_poll）

（4）以tcp_poll為例，其核心實(shí)現(xiàn)就是__pollwait，也就是上面注冊的回調(diào)函數(shù)。

（5）__pollwait的主要工作就是把current（當(dāng)前進(jìn)程）掛到設(shè)備的等待隊(duì)列中，不同的設(shè)備有不同的等待隊(duì)列，對于tcp_poll 來說，其等待隊(duì)列是sk->sk_sleep（注意把進(jìn)程掛到等待隊(duì)列中并不代表進(jìn)程已經(jīng)睡眠了）。在設(shè)備收到一條消息（網(wǎng)絡(luò)設(shè)備）或填寫完文件數(shù) 據(jù)（磁盤設(shè)備）后，會喚醒設(shè)備等待隊(duì)列上睡眠的進(jìn)程，這時(shí)current便被喚醒了。

（6）poll方法返回時(shí)會返回一個(gè)描述讀寫操作是否就緒的mask掩碼，根據(jù)這個(gè)mask掩碼給fd_set賦值。

（7）如果遍歷完所有的fd，還沒有返回一個(gè)可讀寫的mask掩碼，則會調(diào)用schedule_timeout是調(diào)用select的進(jìn)程（也就是 current）進(jìn)入睡眠。當(dāng)設(shè)備驅(qū)動發(fā)生自身資源可讀寫后，會喚醒其等待隊(duì)列上睡眠的進(jìn)程。如果超過一定的超時(shí)時(shí)間（schedule_timeout 指定），還是沒人喚醒，則調(diào)用select的進(jìn)程會重新被喚醒獲得CPU，進(jìn)而重新遍歷fd，判斷有沒有就緒的fd。

（8）把fd_set從內(nèi)核空間拷貝到用戶空間。

總結(jié)下select的幾大缺點(diǎn)：

（1）每次調(diào)用select，都需要把fd集合從用戶態(tài)拷貝到內(nèi)核態(tài)，這個(gè)開銷在fd很多時(shí)會很大

（2）同時(shí)每次調(diào)用select都需要在內(nèi)核遍歷傳遞進(jìn)來的所有fd，這個(gè)開銷在fd很多時(shí)也很大

（3）select支持的文件描述符數(shù)量太小了，默認(rèn)是1024

2．? poll與select不同，通過一個(gè)pollfd數(shù)組向內(nèi)核傳遞需要關(guān)注的事件，故沒有描述符個(gè)數(shù)的限制，pollfd中的events字段和revents分別用于標(biāo)示關(guān)注的事件和發(fā)生的事件，故pollfd數(shù)組只需要被初始化一次。

poll的實(shí)現(xiàn)機(jī)制與select類似，其對應(yīng)內(nèi)核中的sys_poll，只不過poll向內(nèi)核傳遞pollfd數(shù)組，然后對pollfd中的每個(gè)描述符進(jìn)行poll，相比處理fdset來說，poll效率更高。poll返回后，需要對pollfd中的每個(gè)元素檢查其revents值，來得指事件是否發(fā)生。

3．直到Linux2.6才出現(xiàn)了由內(nèi)核直接支持的實(shí)現(xiàn)方法，那就是epoll，被公認(rèn)為Linux2.6下性能最好的多路I/O就緒通知方法。epoll可以同時(shí)支持水平觸發(fā)和邊緣觸發(fā)（Edge Triggered，只告訴進(jìn)程哪些文件描述符剛剛變?yōu)榫途w狀態(tài)，它只說一遍，如果我們沒有采取行動，那么它將不會再次告知，這種方式稱為邊緣觸發(fā)），理論上邊緣觸發(fā)的性能要更高一些，但是代碼實(shí)現(xiàn)相當(dāng)復(fù)雜。epoll同樣只告知那些就緒的文件描述符，而且當(dāng)我們調(diào)用epoll_wait()獲得就緒文件描述符時(shí)，返回的不是實(shí)際的描述符，而是一個(gè)代表就緒描述符數(shù)量的值，你只需要去epoll指定的一個(gè)數(shù)組中依次取得相應(yīng)數(shù)量的文件描述符即可，這里也使用了內(nèi)存映射（mmap）技術(shù)，這樣便徹底省掉了這些文件描述符在系統(tǒng)調(diào)用時(shí)復(fù)制的開銷。另一個(gè)本質(zhì)的改進(jìn)在于epoll采用基于事件的就緒通知方式。在select/poll中，進(jìn)程只有在調(diào)用一定的方法后，內(nèi)核才對所有監(jiān)視的文件描述符進(jìn)行掃描，而epoll事先通過epoll_ctl()來注冊一個(gè)文件描述符，一旦基于某個(gè)文件描述符就緒時(shí)，內(nèi)核會采用類似callback的回調(diào)機(jī)制，迅速激活這個(gè)文件描述符，當(dāng)進(jìn)程調(diào)用epoll_wait()時(shí)便得到通知。

epoll既然是對select和poll的改進(jìn)，就應(yīng)該能避免上述的三個(gè)缺點(diǎn)。那epoll都是怎么解決的呢？在此之前，我們先看一下epoll 和select和poll的調(diào)用接口上的不同，select和poll都只提供了一個(gè)函數(shù)——select或者poll函數(shù)。而epoll提供了三個(gè)函 數(shù)，epoll_create,epoll_ctl和epoll_wait，epoll_create是創(chuàng)建一個(gè)epoll句柄；epoll_ctl是注 冊要監(jiān)聽的事件類型；epoll_wait則是等待事件的產(chǎn)生。

　　對于第一個(gè)缺點(diǎn)，epoll的解決方案在epoll_ctl函數(shù)中。每次注冊新的事件到epoll句柄中時(shí)（在epoll_ctl中指定 EPOLL_CTL_ADD），會把所有的fd拷貝進(jìn)內(nèi)核，而不是在epoll_wait的時(shí)候重復(fù)拷貝。epoll保證了每個(gè)fd在整個(gè)過程中只會拷貝 一次。

　　對于第二個(gè)缺點(diǎn)，epoll的解決方案不像select或poll一樣每次都把current輪流加入fd對應(yīng)的設(shè)備等待隊(duì)列中，而只在 epoll_ctl時(shí)把current掛一遍（這一遍必不可少）并為每個(gè)fd指定一個(gè)回調(diào)函數(shù)，當(dāng)設(shè)備就緒，喚醒等待隊(duì)列上的等待者時(shí)，就會調(diào)用這個(gè)回調(diào) 函數(shù)，而這個(gè)回調(diào)函數(shù)會把就緒的fd加入一個(gè)就緒鏈表）。epoll_wait的工作實(shí)際上就是在這個(gè)就緒鏈表中查看有沒有就緒的fd（利用 schedule_timeout()實(shí)現(xiàn)睡一會，判斷一會的效果，和select實(shí)現(xiàn)中的第7步是類似的）。

　　對于第三個(gè)缺點(diǎn)，epoll沒有這個(gè)限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個(gè)數(shù)字一般遠(yuǎn)大于2048,舉個(gè)例子, 在1GB內(nèi)存的機(jī)器上大約是10萬左右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來說這個(gè)數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大。

總結(jié)：

（1）select，poll實(shí)現(xiàn)需要自己不斷輪詢所有fd集合，直到設(shè)備就緒，期間可能要睡眠和喚醒多次交替。而epoll其實(shí)也需要調(diào)用 epoll_wait不斷輪詢就緒鏈表，期間也可能多次睡眠和喚醒交替，但是它是設(shè)備就緒時(shí)，調(diào)用回調(diào)函數(shù)，把就緒fd放入就緒鏈表中，并喚醒在 epoll_wait中進(jìn)入睡眠的進(jìn)程。雖然都要睡眠和交替，但是select和poll在“醒著”的時(shí)候要遍歷整個(gè)fd集合，而epoll在“醒著”的 時(shí)候只要判斷一下就緒鏈表是否為空就行了，這節(jié)省了大量的CPU時(shí)間，這就是回調(diào)機(jī)制帶來的性能提升。

（2）select，poll每次調(diào)用都要把fd集合從用戶態(tài)往內(nèi)核態(tài)拷貝一次，并且要把current往設(shè)備等待隊(duì)列中掛一次，而epoll只要 一次拷貝，而且把current往等待隊(duì)列上掛也只掛一次（在epoll_wait的開始，注意這里的等待隊(duì)列并不是設(shè)備等待隊(duì)列，只是一個(gè)epoll內(nèi) 部定義的等待隊(duì)列），這也能節(jié)省不少的開銷。

這三種IO多路復(fù)用模型在不同的平臺有著不同的支持，而epoll在windows下就不支持，好在我們有selectors模塊，幫我們默認(rèn)選擇當(dāng)前平臺下最合適的

#服務(wù)端from socket import *import selectors

sel=selectors.DefaultSelector()def accept(server_fileobj,mask):

? ? conn,addr=server_fileobj.accept()

? ? sel.register(conn,selectors.EVENT_READ,read)def read(conn,mask):

? ? try:

? ? ? ? data=conn.recv(1024)

? ? ? ? if not data:

? ? ? ? ? ? print('closing',conn)

? ? ? ? ? ? sel.unregister(conn)

? ? ? ? ? ? conn.close()

? ? ? ? ? ? return? ? ? ? conn.send(data.upper()+b'_SB')

? ? except Exception:

? ? ? ? print('closing', conn)

? ? ? ? sel.unregister(conn)

? ? ? ? conn.close()

server_fileobj=socket(AF_INET,SOCK_STREAM)

server_fileobj.setsockopt(SOL_SOCKET,SO_REUSEADDR,1)

server_fileobj.bind(('127.0.0.1',8088))

server_fileobj.listen(5)

server_fileobj.setblocking(False) #設(shè)置socket的接口為非阻塞sel.register(server_fileobj,selectors.EVENT_READ,accept) #相當(dāng)于網(wǎng)select的讀列表里append了一個(gè)文件句柄server_fileobj,并且綁定了一個(gè)回調(diào)函數(shù)acceptwhile True:

? ? events=sel.select() #檢測所有的fileobj，是否有完成wait data的? ? for sel_obj,mask in events:

? ? ? ? callback=sel_obj.data #callback=accpet? ? ? ? callback(sel_obj.fileobj,mask) #accpet(server_fileobj,1)#客戶端from socket import *

c=socket(AF_INET,SOCK_STREAM)

c.connect(('127.0.0.1',8088))while True:

? ? msg=input('>>: ')

? ? if not msg:continue? ? c.send(msg.encode('utf-8'))

? ? data=c.recv(1024)

? ? print(data.decode('utf-8'))