快來幫忙找,IPDL 在哪裡?

作者:
瀏覽:671

截止目前為止,Mozilla 的 IPC 在我心目中依然是個仰之彌高,鑽之彌堅,瞻之在前,忽焉在後[1]的神秘技術,雖然簡單地說,它就只是 Content Process 和 Chrome Process 溝通橋樑…而已(心虛)。

總之,有了 IPC 這座橋,接下來是讓程式設計師知道如何利用 IPC 這座橋,就如同專供定義 XPCOM/DOM 物件的 IDL/WebIDL 一樣,IPDL 便是用來定義 IPC 的語言(IPC Protocol Definition Language),也一樣會在編譯期自動產生對應的物件型別定義,再由程式設計師將功能實作出來;但與 IDL/WebIDL 不同的是,因為 IPDL 定義的是 Gecko 核心的功能,因此一定要用 C++ 實作。

在開發 Firefox OS 的 Web API 過程中,IPDL 是一個讓人避之唯恐不及知易行難的元素,因為定義與實作必需遵循一套命名規則,但是可供參考的文件相對不多,又實作 IPDL 的程式碼容易混淆且與應用相關,即使是參考現有程式仍然會有不小的學習曲線。

不過它很重要,所以我們要跟它做朋友、接近它、靠近它、了解它、把它的底摸得清清楚楚[2]-雖然我現在跟它並不太熟。

回到正題,IPDL 在哪裡?

若把 IPDL 當成一個定義 IPC 的工具語言,這是個沒有意義的問題(雖然它本來就是);不過更多時候,我們所謂的 IPDL 指的是 IPDL 所定義出來的 IPC 架構,以此而言,IPDL 就在 Content Process 和 Chrome Process 之間…嗯,你知道,我知道,獨眼龍也知道[3],但是當我處理 Bug 859215 的時候,第一次看到活生生的 IPDL,還是沒辦法具現化想像它所定義出來的各個物件,在整個流程中所在的位置和呼叫順序。

所以我畫了張圖,而且比威利在哪裡簡單得多(先看完這一篇再去玩吧),一眼就能看 IPDL 的整個架構和各個物件在流程中扮演的角色。

快來幫忙找,IPDL 在哪裡?

Bug 859215程式流程簡圖(點小圖看大圖)

*由於這張圖是針對 Mobile Message DOM 做的,還是需要讀者對 Mobile Message DOM 有一點瞭解,並參考對應的 IPDL patch

如前所述,在 IPC 的大架構之下,IPDL 的定義及實作方式與使用場合的相關性很大,例如圖中 Content Process 往 Chrome Process 的 IPC,Client 的角色便不是由標準說明上的 SmsRequestChild 擔任,而是由 SmsIPCService 擔任。因此本文呈現的只是 IPDL 的其中一種樣子,換個位置可能也就換了腦袋樣子,但若能在 trace code 的同時畫出 IPDL 的流程,相信能有效地提高掌握度(而且忘記了也好查)。

最後補充一些小細節:

  1. 為什麼 Content Process 的 SmsService 能呼叫到 SmsIPCService
    參考程式碼,要在 Content Process 取得 SmsService ,實際上會拿到 SmsIPCService;相對地在 Chrome Process 中則會拿到 SmsService。
    因此 SmsIPCService 必需支援所有 SmsService 的介面,並將之轉成 IPC 往 Chorme Process 送。
  2. pSMS.ipdl 和 pSmsRequest.ipdl 的關係
    pSMS.ipdl 定義了整個 IPC 的訊息架構,包含 SmsIPCService 往 smsRequestParent 和 smsRequestParent 往 smsRequestClient 兩個方向的介面,以及圖中 SmsIPCService 往 smsRequestParent 方向的訊息格式。
    而 pSmsRequest.ipdl 定義的是圖中 smsRequestParent 送往 smsRequestChild 的訊息格式。

[1] 出自論語,顏回說的
[2] 出自小孩不笨,李老師說的前幾段是為了提起各位的興趣來著,絕對不是騙稿費
[3] 出自賭俠,劉德華賭俠說的