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

2. 进程间的跨线程通信和同步通信

在Chrome中，任何底层的数据都是线程非安全的，Channel不是太上老君（抑或中国足球？...），它也没有例外。在每一个进程中，只能有一个线程来负责操作Channel，这个线程叫做IO线程（名不符实真是一件悲凉的事情...）。其它线程要是企图越俎代庖，是会出大乱子的。。。

但是有时候（其实是大部分时候...），我们需要从非IO线程与别的进程相通信，这该如何是好？如果，你有看过我前面写的线程模型，你一定可以想到，做法很简单，先将对Channel的操作放到Task中，将此Task放到IO线程队列里，让IO线程来处理即可。当然，由于这种事情发生的太频繁，每次都人肉做一次颇为繁琐，于是有一个代理类，叫做ChannelProxy，来帮助你完成这一切。。。

从接口上看，ChannelProxy的接口和Channel没有大的区别（否则就不叫Proxy了...），你可以像用Channel一样，用ChannelProxy来Send你的消息，ChannelProxy会辛勤的帮你完成剩余的封装Task等工作。不仅如此，ChannelProxy还青出于蓝胜于蓝，在这个层面上做了更多的事情，比如：发送同步消息。。。

不过能发送同步消息的类不是ChannelProxy，而是它的子类，SyncChannel。在Channel那里，所有的消息都是异步的（在Windows中，也叫Overlapped...），其本身也不支持同步逻辑。为了实现同步，SyncChannel并没有另造轮子，而只是在Channel的层面上加了一个等待操作。当ChannelProxy的Send操作返回后，SyncChannel会把自己阻塞在一组信号量上，等待回包，直到永远或超时。从外表上看同步和异步没有什么区别，但在使用上还是要小心，在UI线程中使用同步消息，是容易被发指的。。。

3. Chrome中的IPC消息格式

说了半天，还有一个大头没有提过，那就是消息包。如果说，多线程模式下，对数据的访问开销来自于锁，那么在多进程模式下，大部分的额外开销都来自于进程间的消息拆装和传递。不论怎么样的模式，只要进程不同，消息的打包，序列化，反序列化，组包，都是不可避免的工作。。。

在Chrome中，IPC之间的通信消息，都是派生自IPC::Message类的。对于消息而言，序列化和反序列化是必须要支持的，Message的基类Pickle，就是干这个活的。Pickle提供了一组的接口，可以接受int，char，等等各种数据的输入，但是在Pickle内部，所有的一切都没有区别，都转化成了一坨二进制流。这个二进制流是32位齐位的，比如你只传了一个bool，也是最少占32位的，同时，Pickle的流是有自增逻辑的（就是说它会先开一个Buffer，如果满了的话，会加倍这个Buffer...），使其可以无限扩展。Pickle本身不维护任何二进制流逻辑上的信息，这个任务交到了上级处理（后面会有说到...），但Pickle会为二进制流添加一个头信息，这个里面会存放流的长度，Message在继承Pickle的时候，扩展了这个头的定义，完整的消息格式如下：



图6 Chrome的IPC消息格式
其中，***部分是包头，定长96个bit，绿色部分是包体，二进制流，由payload_size指明长度。从大小上看这个包是很精简的了，除了routing位在消息不为路由消息的时候会有所浪费。消息本身在有名管道中是按照二进制流进行传输的（有名管道可以传输两种类型的字符流，分别是二进制流和消息流...），因此由payload_size + 96bits，就可以确定是否收了一个完整的包。。。

从逻辑上来看，IPC消息分成两类，一类是路由消息（routed message），还有一类是控制消息（control message）。路由消息是私密的有目的地的，系统会依照路由信息将消息安全的传递到目的地，不容它人窥视；控制消息就是一个广播消息，谁想听等能够听得到。。。

消息的序列化

前不久读了Google Protocol Buffers的源码，是用在服务器端，用做内部机器通信协议的标准、代码生成工具和框架。它主要的思想是揉合了key/value的内容到二进制中，帮助生成更为灵活可靠的二进制协议。。。

在Chrome中，没有使用这套东西，而是用到了纯二进制流作为消息序列化的方式。我想这是由于应用场景不同使然。在服务端，我们更关心协议的稳定性，可扩展性，并且，涉及到的协议种类很多。但在一个Chrome中，消息的格式很统一，这方面没有扩展性和灵活性的需求，而在序列化上，虽然key/value的方式很好很强大，但是在Chrome中需要的不是灵活性而是精简性，因此宁可不用Protocol Buffers造好的轮子，而是另立炉灶，花了好一把力气提供了一套纯二进制的消息机制。。。