IO模型多路復用

乙個輸入操作通常包括兩個階段：

應用程序被阻塞，直到資料從核心緩衝區複製到應用程序緩衝區中才返回。

應該注意到，在阻塞的過程中，其它應用程序還可以執行，因此阻塞不意味著整個作業系統都被阻塞。因為其它應用程序還可以執行，所以不消耗 cpu 時間，這種模型的 cpu 利用率會比較高。

應用程序執行系統呼叫之後，核心返回乙個錯誤碼。應用程序可以繼續執行，但是需要不斷的執行系統呼叫來獲知i/o 是否完成，這種方式稱為輪詢（polling）。

由於 cpu 要處理更多的系統呼叫，因此這種模型的 cpu 利用率比較低。

使用 select 或者 poll 等待資料，並且可以等待多個套接字中的任何乙個變為可讀。這一過程會被阻塞，當某乙個套接字可讀時返回，之後再使用 recvfrom 把資料從核心複製到程序中。

應用程序使用 sigaction 系統呼叫，核心立即返回，應用程序可以繼續執行，也就是說等待資料階段應用程序是非阻塞的。核心在資料到達時向應用程序傳送 sigio 訊號，應用程序收到之後在訊號處理程式中呼叫 recvfrom 將資料從核心複製到應用程序中。

相比於非阻塞式 i/o (nio)的輪詢方式，訊號驅動 i/o 的 cpu 利用率更高。

應用程序執行 aio_read 系統呼叫會立即返回，應用程序可以繼續執行，不會被阻塞，核心會在所有操作完成之後向應用程序傳送訊號。

非同步 i/o 與訊號驅動 i/o 的區別在於，非同步 i/o 的訊號是通知應用程序 i/o 完成，而訊號驅動 i/o 的訊號是通知應用程序可以開始 i/o。

同步 i/o：將資料從核心緩衝區複製到應用程序緩衝區的階段（第二階段），應用程序會阻塞。

非同步 i/o：第二階段應用程序不會阻塞。功能

速度

可移植性

幾乎所有的系統都支援 select，但是只有比較新的系統支援 poll。

很容易產生一種錯覺認為只要用 epoll 就可以了，select 和 poll 都已經過時了，其實它們都有各自的使用場景。

select 應用場景

select 的 timeout 引數精度為 1ns，而 poll 和 epoll 為 1ms，因此 select 更加適用於實時性要求比較高的場景，比如核反應堆的控制。

select 可移植性更好，幾乎被所有主流平台所支援。

poll 應用場景

poll 沒有最大描述符數量的限制，如果平台支援並且對實時性要求不高，應該使用 poll 而不是 select。

epoll 應用場景

只需要執行在 linux 平台上，有大量的描述符需要同時輪詢，並且這些連線最好是長連線。

需要同時監控小於 1000 個描述符，就沒有必要使用 epoll，因為這個應用場景下並不能體現 epoll 的優勢。

需要監控的描述符狀態變化多，而且都是非常短暫的，也沒有必要使用 epoll。因為 epoll 中的所有描述符都儲存在核心中，造成每次需要對描述符的狀態改變都需要通過 epoll_ctl() 進行系統呼叫，頻繁系統呼叫降低效率。並且epoll 的描述符儲存在核心，不容易除錯。

IO模型 多路復用