PHP FPM源代碼反芻品味之二：IO多路複用

基礎:操做系統IO多路複用機制。

IO多路複用機制,常見的實現方法有select,poll,epoll,kqueue.
IO多路複用是服務器程序開發的核心，也是研究服務器程序源代碼的基礎。
這裏作個簡單的介紹。

這裏試圖用非程序的方式來講明這個機制。

舉個例子：

辦公室有3個可加熱飲料機,分別提供橙汁，茶水，豆漿。
飲料機有一個指示燈，紅色表示正在加熱，綠色表示完成加熱。
有3個水壺用於裝熱飲，這裏假設，水壺容量很大，飲料機要屢次加熱才能裝滿一壺。
會議室要開會，任務：接滿3水壺加熱完成的飲料到會議室備用。

問題：怎麼接滿三水壺熱飲？

（這個問題也太簡單了吧，有必要討論嗎？）

辦法一：
先拿個一水壺接橙汁，指示燈爲紅色時等待，綠色時接，飲料機屢次加熱，屢次等待，等接滿一壺後，在一樣的一次接滿茶水，豆漿。
這個辦法很簡單，只需依次等待。
當咱們會發現，在等待橙汁加熱的時候，茶水和豆漿可能已經加熱就緒了。

因而咱們改進了這個辦法。

辦法二：
同時監控3個飲料機的指示燈，哪一個燈變綠，就去接哪一個。
這樣效率提升了不少。

細節上看，辦法一很簡單，只需依次操做。
辦法二，減小了等待時間，多了一個監控工做。

這裏還有個飲料機列表的概念，和飲料機添加，移除操做。
即須要哪些飲料機，和需求變更的操做。
以上例子，咱們需求是橙汁，茶水和豆漿，若是需求變更，須要加入牛奶或者不須要豆漿。
辦法一和辦法二的飲料機列表要作調整，這一點二者是相似的。

可是辦法二也有不足的地方：須要時時查看指示燈的狀態。
只有3個飲料機的狀況，不易察覺這個過程，試想若是有1000個飲料機，咱們要挨個查看這1000個指示燈。

因而咱們改進了這個方法。

辦法三：
每一個飲料機加個聲音提示功能，即加熱完成後聲音提醒一下。
這樣的好處是在多個飲料機的狀況下，咱們不用時時檢查每一個指示燈的狀態。
從主動檢查變成被動提醒的改進，大大提升了效率。這就是傳說中的基於事件的IO多路複用機制
如今咱們感受良好了，當還有改進的地方，

試想下，若是天氣寒冷，電力不足，飲料加熱很慢。
即便咱們同時監控3個飲料機，也會等待好久，即長時間沒有任何一個加熱就緒的信號。
同時咱們還有其餘任務，諸如打印報表，準備投影儀等。

聰明的人變想到，不能這樣一直等下去，等一下子，飲料機沒動靜，就去作其餘事，其餘事作好了，再過來接飲料。
這裏引入了一個超時的概念，即一次等待最長的時間。（固然，能夠設定不超時）

加入了超時支持，辦法三的效率就更高了，這也是如今多數服務器程序的機制。

整個舉例中有個隱含的要求就是，一個水壺不能同時裝兩種飲料。
即一個水壺一次只能裝同一種飲料，橙汁和茶水不能混在一塊兒。
這話彷佛有些多餘，橙汁和茶水混在一塊兒是很顯然的錯誤。

對於程序開發，這個錯誤卻很容易發生 .
因此這裏作個提醒: 橙汁和茶水必要混在一塊兒，味道很差。

以上爲平常例子，如今回到技術：
一個飲水機的水龍頭至關於一個輸入的文件句柄（fd）,
指示燈變綠，句柄可讀信號。
水壺表示緩衝（BUFFER）
這個例子以輸出爲例，輸入的狀況相似。

辦法二對應與select方法，也能夠加入超時設置。這個方法由於效率不高，已被epoll或kqueue取代，一些開源軟件在windows下面使用這個方法。辦法三對應於epoll，kqueue方法，由於高效，分別在Linux和FreeBSD平臺普遍使用。