Chrome源码剖析--Chrome的多线程模型 下

4. 定义IPC消息

如果你写过MFC程序，对MFC那里面一大堆宏有所忌惮的话，那么很不幸，在Chrome中的IPC消息定义中，你需要再吃一点苦头了，甚至，更苦大仇深一些；如果你曾经领教过用模板的特化偏特化做Traits、用模板做函数重载、用编译期的Tuple做变参数支持，之类机制的种种麻烦的话，那么，同样很遗憾，在Chrome中，你需要再感受一次。。。

不过，先让我们忘记宏和模板，看人肉一个消息，到底需要哪些操作。一个标准的IPC消息定义应该是类似于这样的：

 

class SomeMessage

    : public IPC::Message
{
public:
    enum { ID = ...; }
    SomeMessage(SomeType & data) 
        : IPC::Message(MSG_ROUTING_CONTROL, ID, ToString(data)) 
    {...}
    ...
};

 

大概意思是这样的，你需要从Message（或者其他子类）派生出一个子类，该子类有一个独一无二的ID值，该子类接受一个参数，你需要对这个参数进行序列化。两个麻烦的地方看的很清楚，如果生成独一无二的ID值？如何更方便的对任何参数可以自动的序列化？。。。

在Chrome中，解决这两个问题的答案，就是宏 + 模板。Chrome为每个消息安排了一种ID规格，用一个16bits的值来表示，高4位标识一个Channel，低12位标识一个消息的子id，也就是说，最多可以有16种Channel存在不同的进程之间，每一种Channel上可以定义4k的消息。目前，Chrome已经用掉了8种Channel（如果A、B进程需要双向通信，在Chrome中，这是两种不同的Channel，需要定义不同的消息，也就是说，一种双向的进程通信关系，需要耗费两个Channel种类...），他们已经觉得，16bits的ID格式不够用了，在将来的某一天，估计就被扩展成了32bits的。书归正传，Chrome是这么来定义消息ID的，用一个枚举类，让它从高到低往下走，就像这样：

 

enum SomeChannel_MsgType

{
    SomeChannelStart = 5 << 12,
    SomeChannelPreStart = (5 << 12) - 1,
    Msg1,
    Msg2,
    Msg3,
    ...
    MsgN,
    SomeChannelEnd
};

 

这是一个类型为5的Channel的消息ID声明，由于指明了最开始的两个值，所以后续枚举的值会依次递减，如此，只要维护Channel类型的唯一性，就可以维护所有消息ID的唯一性了（当然，前提是不能超过消息上限...）。但是，定义一个ID还不够，你还需要定义一个使用该消息ID的Message子类。这个步骤不但繁琐，最重要的，是违反了DIY原则，为了添加一个消息，你需要在两个地方开工干活，是可忍孰不可忍，于是Google祭出了宏这颗原子弹，需要定义消息，格式如下：

 

IPC_BEGIN_MESSAGES(PluginProcess, 3)
  
  IPC_MESSAGE_CONTROL2(PluginProcessMsg_CreateChannel,
                       int /* process_id */,
                       HANDLE /* renderer handle */)

  IPC_MESSAGE_CONTROL1(PluginProcessMsg_ShutdownResponse,
                       bool /* ok to shutdown */)

  IPC_MESSAGE_CONTROL1(PluginProcessMsg_PluginMessage,
                       std::vector<uint8> /* opaque data */)

  IPC_MESSAGE_CONTROL0(PluginProcessMsg_BrowserShutdown)

IPC_END_MESSAGES(PluginProcess)

 

这是Chrome中，定义PluginProcess消息的宏，我挖过来放在这了，如果你想添加一条消息，只需要添加一条类似与IPC_MESSAGE_CONTROL0东东即可，这说明它是一个控制消息，参数为0个。你基本上可以这样理解，IPC_BEGIN_MESSAGES就相当于完成了一个枚举开始的声明，然后中间的每一条，都会在枚举里面增加一个ID，并声明一个子类。这个一宏两吃，直逼北京烤鸭两吃的高超做法，可以参看ipc_message_macros.h，或者看下面一宏两吃的一个举例。。。

多次展开宏的技巧

这是Chrome中用到的一个技巧，定义一次宏，展开多段代码，我孤陋寡闻，第一次见，一个类似的例子，如下：

首先，定义一个macro.h，里面放置宏的定义：

 

#undef SUPER_MACRO

#if defined(FIRST_TIME)
#undef FIRST_TIME

#define SUPER_MACRO(label, type) /
enum IDs { /
label##__ID = 10 /
};

#elif defined(SECOND_TIME)
#undef SECOND_TIME

#define SUPER_MACRO(label, type) /
class TestClass /
{ /
public: /
enum {ID = label##__ID}; /
TestClass(type value) : _value(value) {} /
type _value; /
};

#endif

 

可以看到，这个头文件是可重入的，每一次先undef掉之前的定义，然后判断进行新的定义。然后，你可以创建一个use_macro.h文件，利用这个宏，定义具体内容：

#include "macros.h"

SUPER_MACRO(Test, int)

这个头文件在利用宏的部分不需要放到ifundef...define...这样的头文件保护中，目的就是为了可重入。在主函数中，你可以多次define + include，实现多次展开的目的：

 

#define FIRST_TIME
#include "use_macro.h"

#define SECOND_TIME
#include "use_macro.h"

#include <iostream>

int _tmain(int argc, _TCHAR* argv[])
{
TestClass t(5);
std::cout << TestClass::ID << std::endl;
std::cout << t._value << std::endl;

return 0;
}

 

这样，你就成功的实现，一次定义，生成多段代码了。。。

此外，当接收到消息后，你还需要处理消息。接收消息的函数，是IPC::Channel::Listener子类的OnMessageReceived函数。在这个函数中，会放置一坨的宏，这一套宏，一定能让你想起MFC的Message Map机制：

 

    IPC_BEGIN_MESSAGE_MAP_EX(RenderProcessHost, msg, msg_is_ok)

      IPC_MESSAGE_HANDLER(ViewHostMsg_PageContents, OnPageContents)
      IPC_MESSAGE_HANDLER(ViewHostMsg_UpdatedCacheStats,
                          OnUpdatedCacheStats)
      IPC_MESSAGE_UNHANDLED_ERROR()
    IPC_END_MESSAGE_MAP_EX()

 

这个东西很简单，展开后基本可以视为一个Switch循环，判断消息ID，然后将消息，传递给对应的函数。与MFC的Message Map比起来，做的事情少多了。。。

通过宏的手段，可以解决消息类声明和消息的分发问题，但是自动的序列化还不能支持（所谓自动的序列化，就是不论你是什么类型的参数，几个参数，都可以直接序列化，不需要另写代码...）。在C++这种语言中，所谓自动的序列化，自动的类型识别，自动的XXX，往往都是通过模板来实现的。这些所谓的自动化，其实就是通过事前的大量人肉劳作，和模板自动递推来实现的，如果说.Net或Java中的自动序列化是过山轨道，这就是那挑夫的骄子，虽然最后都是两腿不动到了山顶，这底下费得力气真是天壤之别啊。具体实现技巧，有兴趣的看看《STL源码剖析》，或者是《C++新思维》，或者Chrome中的ipc_message_utils.h，这要说清楚实在不是一两句的事情。。。

总之通过宏和模板，你可以很简单的声明一个消息，这个消息可以传入各式各样的参数（这里用到了夸张的修辞手法，其实，只要是模板实现的自动化，永远都是有限制的，在Chrome的模板实现中，参数数量不要超过5个，类型需要是基本类型、STL容器等，在不BT的场合，应该够用了...），你可以调用Channel、ChannelProxy、SyncChannel之类的Send方法，将消息发送给其他进程，并且，实现一个Listener类，用Message Map来分发消息给对应的处理函数。如此，整个IPC体系搭建完成。。。

苦力的宏和模板

不论是宏还是模板，为了实现这套机制，都需要写大量的类似代码，比如为了支持0~N个参数的Control消息，你就需要写N+1个类似的宏；为了支持各种基础数据结构的序列化，你就需要写上十来个类似的Write函数和Traits。。。

之所以做如此苦力的活，都是为了用这些东西的人能够尽可能的简单方便，符合DIY原则。规约到之前说的设计者的职责上来，这是一个典型的苦了我一个幸福千万人的负责任的行为。在Chrome中，如此的代码随处可见，光Tuple那一套拳法，我现在就看到了使了不下三次（我曾经做过一套，直接吐血...），如此兢兢业业，真是可歌可泣啊。。。