我們編寫驅動程式的時候，通常需要告訴上層應用程式裝置的狀態：是否可讀寫。
應用程式可以直接通過read/write系統呼叫(阻塞和非阻塞模式)進入核心態驅動程式，那麼驅動程式的read/write至少需要支援阻塞和非阻塞模式的讀寫：
上層阻塞模式呼叫read時，如果裝置驅動的read_buffer中沒有資料可以供上層讀取,就讓該程序睡眠(阻塞)直到有資料才被喚醒，然後取到資料返回使用者態；如果是非阻塞模式呼叫read時，read_buffer中沒有資料直接返回0。
上層阻塞模式呼叫write時，如果裝置驅動的write_buffer已滿沒有空間寫入資料，就讓該程序睡眠(阻塞)直到write_buffer中有空間可以寫入資料才被喚醒，然後將資料寫入write_buffer後返回使用者態；如果是非阻塞模式呼叫write時，write_buffer中沒有空間直接返回0。
如果乙個應用程式需要同時訪問多個硬體裝置，此時就不能使用阻塞模式開啟裝置了，否則整個程序可能就阻塞在了某個硬體上。這種情況可以採用如下非同步的方式：有資料可讀返回資料個數，沒有返回0或者-1，應用程式每隔一段時間就對依次各個裝置進行讀取，對單個裝置來說有資料就返回資料，沒有就返回0，當所有裝置遍歷完之後，繼續睡眠，時間間隔到再喚醒繼續這樣的動作。這樣程序反覆睡眠喚醒對系統效率影響很大。
對於這個問題，linux提供了另外乙個方法，select和poll的方式: 這種方式下，應用程式將輪詢程序所有裝置檔案描述符的工作交給了作業系統，這樣應用程式中只需阻塞在select或者poll系統呼叫中，返回後，肯定至少有乙個裝置檔案描述符的狀態有發生改變，要不然該應用程序的阻塞是不會退出的。
本次研究主要問題集中在：
select和poll系統呼叫在應用程式中如何使用？
select和poll系統呼叫中如何實現同時監測多個裝置檔案描述符？
select, poll和epoll的區別
我只用過select select 最不能忍受的是乙個程序所開啟的fd是有一定限制的，由fd setsize設定，預設值是2048。對於那些需要支援的上萬連線數目的im伺服器來說顯然太少了,select要掃瞄各個檔案描述符，而epool採用mmap更高效 select 系統呼叫提供乙個機制來實現同步...
select poll和epoll的區別
select，poll，epoll都是io多路復用的機制。i o多路復用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒 一般是讀就緒或者寫就緒 能夠通知程式進行相應的讀寫操作。select僅僅知道i o事件發生的檔案描述符的數量，但並不知道是哪幾個 1 時間複雜度 o n 2 優點 跨平台支...
select，poll和epoll的API複習筆記
環境 centos7 xshell 前言 select poll epoll 的區別一定要清楚 select 優點是跨平台,而poll相對其沒有1024檔案描述符的限制,共有的缺點是 1.每次監聽都需要將監聽的資訊從應用層拷貝到核心。2.返回變化的檔案描述符的個數，具體哪個檔案描述符變化需要遍歷。3...