示意圖如下：
這裡select監聽的socket都是non-blocking的，是以在do_read() do_write()中對傳回為eagain/wsaewouldblock都做了處理。
從代碼中可以看出使用select傳回後，仍然需要輪訓再檢測每個socket的狀态（讀、寫），這樣的輪訓檢測在大量連接配接下也是效率不高的。因為當需要探測的句柄值較大時，select () 接口本身需要消耗大量時間去輪詢各個句柄。
很多作業系統提供了更為高效的接口，如 linux 提供 了 epoll，bsd 提供了 kqueue，solaris 提供了 /dev/poll …。如果需要實作更高效的伺服器程式，類似 epoll 這樣的接口更被推薦。遺憾的是不同的作業系統特供的 epoll 接口有很大差異，是以使用類似于 epoll 的接口實作具有較好跨平台能力的伺服器會比較困難。
5、使用事件驅動庫libevent的伺服器模型
libevent 是一種高性能事件循環/事件驅動庫。
為了實際處理每個請求，libevent 庫提供一種事件機制，它作為底層網絡後端的包裝器。事件系統讓為連接配接添加處理函數變得非常簡便，同時降低了底層io複雜性。這是 libevent 系統的核心。
建立 libevent 伺服器的基本方法是，注冊當發生某一操作（比如接受來自用戶端的連接配接）時應該執行的函數，然後調用主事件循環 event_dispatch()。執行過程的控制現在由 libevent 系統處理。注冊事件和将調用的函數之後，事件系統開始自治；在應用程式運作時，可以在事件隊列中添加（注冊）或 删除（取消注冊）事件。事件注冊非常友善，可以通過它添加新事件以處理新打開的連接配接，進而建構靈活的網絡處理系統。
使用libevent實作的一個回顯伺服器如下：
6、信号驅動io模型（signal-driven io）
使用信号，讓核心在描述符就緒時發送sigio信号通知應用程式，稱這種模型為信号驅動式i/o（signal-driven i/o）。
圖示如下：
首先開啟套接字的信号驅動式i/o功能，并通過sigaction系統調用安裝一個信号處理函數。該系統調用将立即傳回，我們的程序繼續工作，也就是說程序沒有被阻塞。當資料報準備好讀取時，核心就為該程序産生一個sigio信号。随後就可以在信号處理函數中調用recvfrom讀取資料報，并通知主循環資料已經準備好待處理，也可以立即通知主循環，讓它讀取資料報。
無論如何處理sigio信号，這種模型的優勢在于等待資料報到達期間程序不被阻塞。主循環可以繼續執行 ，隻要等到來自信号處理函數的通知：既可以是資料已準備好被處理，也可以是資料報已準備好被讀取。
7、異步io模型（asynchronous io）
異步i/o（asynchronous i/o）由posix規範定義。演變成目前posix規範的各種早起标準所定義的實時函數中存在的差異已經取得一緻。一般地說，這些函數的工作機制是：告知核心啟動某個操作，并讓核心在整個操作（包括将資料從核心複制到我們自己的緩沖區）完成後通知我們。這種模型與前一節介紹的信号驅動模型的主要差別在于：信号驅動式i/o是由核心通知我們何時可以啟動一個i/o操作，而異步i/o模型是由核心通知我們i/o操作何時完成。
我們調用aio_read函數（posix異步i/o函數以aio_或lio_開頭），給核心傳遞描述符、緩沖區指針、緩沖區大小（與read相同的三個參數）和檔案偏移（與lseek類似），并告訴核心當整個操作完成時如何通知我們。該系統調用立即傳回，并且在等待i/o完成期間，我們的程序不被阻塞。本例子中我們假設要求核心在操作完成時産生某個信号，該信号直到資料已複制到應用程序緩沖區才産生，這一點不同于信号驅動i/o模型。
參考：
《unix網絡程式設計》
使用 libevent 和 libev 提高網絡應用性能：http://www.ibm.com/developerworks/cn/aix/library/au-libev/
使用異步 i/o 大大提高應用程式的性能：https://www.ibm.com/developerworks/cn/linux/l-async/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。http://www.cnblogs.com/luxiaoxun/p/3691800.html