1. Chrome程序通訊的基本模式

程序間通訊，叫做IPC（Inter-Process Communication），在Chrome不多的文件中，有一篇就是介紹這個的，在 這裡 。Chrome最主要有三類程序，一類是Browser主程序，我們一直尊稱它老人家為老大；還有一類是各個Render程序，前面也提過了；另外還有一類一直沒說過，是Plugin程序，每一個外掛，在Chrome中都是以程序的形式呈現，等到後面說外掛的時候再提罷了。Render程序和Plugin程序都與老大保持程序間的通訊，Render程序與Plugin程序之間也有彼此聯絡的通路，唯獨是多個Render程序或多個Plugin程序直接，沒有互相聯絡的途徑，全靠老大協調

程序與程序間通訊，需要仰仗作業系統的特性，能玩的花著實不多，在Chrome中，用到的就是有名管道（Named Pipe），只不過，它用一個IPC::Channel類，封裝了具體的實現細節。Channel可以有兩種工作模式，一種是Client，一種是Server，Server和Client分屬兩個程序，維繫一個共同的管道名，Server負責建立該管道，Client會嘗試連線該管道，然後雙發往各自管道緩衝區中讀寫資料（在Chrome中，用的是二進位制流，非同步IO...），完成通訊。。。

管道名字的協商

在Socket中，我們會事先約定好通訊的埠，如果不按照這個埠進行訪問，走錯了門，會被直接亂棍打出門去的。與之類似，有名管道期望在兩個程序間遊走，就需要拿一個兩個程序都能接受的進門暗號，這個就是有名管道的名字。在Chrome中（windows下...），有名管道的名字格式都是：//./pipe/chrome.ID

如果不瞭解並期待了解有關Windows下有名管道和訊號量的知識，建議去看一些專業的書籍，比如聖經級別的《Windows核心程式設計》和《深入解析Windows作業系統》，當然也可以去檢視SDK，你需要了解的API可能包括：CreateNamedPipe, CreateFile, ConnectNamedPipe, WaitForMultipleObjects, WaitForSingleObject, SetEvent, 等等。。。

Channel中，有三個比較關鍵的角色，一個是Message::Sender，一個是Channel::Listener，最後一個是MessageLoopForIO::Watcher。Channel本身派生自Sender和Watcher，身兼兩角，而Listener是一個抽象類，具體由Channel的使用者來實現。顧名思義，Sender就是傳送訊息的介面，Listener就是處理接收到訊息的具體實現，但這個Watcher是啥？如果你覺得Watcher這東西看上去很眼熟的話，我會激動的熱淚盈眶的，沒錯，在前面（第一部分第一小節...）說訊息迴圈的時候，從那個表中可以看到，IO執行緒（記住，在Chrome中，IO指的是網路IO，*_*）的迴圈會處理註冊了的Watcher。其實Watcher很簡單，可以視為一個訊號量和一個帶有OnObjectSignaled方法物件的對，當訊息迴圈檢測到訊號量開啟，它就會呼叫相應的OnObjectSignaled方法。。。

圖5 Chrome的IPC處理流程圖

一圖解千語，如上圖所示，整個Chrome最核心的IPC流程都在圖上了，期間，刨去了一些錯誤處理等邏輯，如果想看原汁原味的，可以自查Channel類的實現。當有訊息被Send到一個傳送程序的Channel的時候，Channel會把它放在傳送訊息佇列中，如果此時還正在傳送以前的訊息（傳送端被阻塞...），則看一下阻塞是否解除（用一個等待0秒的訊號量等待函式...），然後將訊息佇列中的內容序列化並寫道管道中去。作業系統會維護非同步模式下管道的這一組訊號量，當訊息從傳送程序緩衝區寫到接收程序的緩衝區後，會啟用接收端的訊號量。當接收程序的訊息迴圈，循到了檢查Watcher這一步，並發現有訊號量激活了，就會呼叫該Watcher相應的OnObjectSignaled方法，通知接受程序的Channel，有訊息來了！Channel會嘗試從管道中收位元組，組訊息，並呼叫Listener來解析該訊息。。。

從上面的描述不難看出，Chrome的程序通訊，最核心的特點，就是利用訊息迴圈來檢查訊號量，而不是直接讓管道阻塞在某訊號量上。這樣就與其多執行緒模型緊密聯絡在了一起，用一種統一的模式來解決問題。並且，由於是訊息迴圈統一檢查，執行緒不會隨便就被阻塞了，可以更好的處理各種其他工作，從理論上講，這是通過增加CPU工作時間，來換取更好的體驗，頗有資本家的派頭。。。

溫柔的訊息迴圈

其實，Chrome的很多訊息迴圈，也不是都那麼霸道，也是會被阻塞在某些訊號量或者某種場景上的，畢竟客戶端不是它家的伺服器，CPU不能被全部歸在它家名下。。。
比如IO執行緒，當沒有訊息來到，又沒有訊號量被啟用的時候，就會被阻塞，具體實現可以去看MessagePumpForIO的WaitForWork方法。。。
不過這種阻塞是集中式的，可隨時修改策略的，比起Channel直接阻塞在訊號量上，停工的時間更短。。。