Chrome

是Plugin进程，每一个插件，在Chrome中都是以进程的形式呈现，等到后面说插件的时候再提罢了。Render进程和Plugin进程都与老大保持进程间的通信，Render进程与Plugin进程之间也有彼此联系的通路，唯独是多个Render进程或多个Plugin进程直接，没有互相联系的途径，全靠老大协调。。。

管道名字的协商
在Socket中，我们会事先约定好通信的端口，如果不按照这个端口进行访问，走错了门，会被直接乱棍打出门去的。与之类似，有名管道期望在两个进程间游走，就需要拿一个两个进程都能接受的进门暗号，这个就是有名管道的名字。在Chrome中（windows下...），有名管道的名字格式都是：//./pipe/chrome.ID。其中的ID，自然是要求独一无二，比如：进程ID.实例地址.随机数。通常，这个ID是由一个Process生成（往往是Browser Process），然后在创建另一个进程的时候，作为命令行参数传进去，从而完成名字的协商。。。

Channel中，有三个比较关键的角色，一个是Message::Sender，一个是Channel::Listener，最后一个是MessageLoopForIO::Watcher。Channel本身派生自Sender和Watcher，身兼两角，而Listener是一个抽象类，具体由Channel的使用者来实现。顾名思义，Sender就是发送消息的接口，Listener就是处理接收到消息的具体实现，但这个Watcher是啥？如果你觉得Watcher这东西看上去很眼熟的话，我会激动的热泪盈眶的，没错，在前面（第一部分第一小节...）说消息循环的时候，从那个表中可以看到，IO线程（记住，在Chrome中，IO指的是网络IO，*_*）的循环会处理注册了的Watcher。其实Watcher很简单，可以视为一个信号量和一个带有OnObjectSignaled方法对象的对，当消息循环检测到信号量开启，它就会调用相应的OnObjectSignaled方法。。。

Chrome的进程通信，最核心的特点，就是利用消息循环来检查信号量，而不是直接让管道阻塞在某信号量上。

温柔的消息循环
其实，Chrome的很多消息循环，也不是都那么霸道，也是会被阻塞在某些信号量或者某种场景上的，毕竟客户端不是它家的服务器，CPU不能被全部归在它家名下。。。
比如IO线程，当没有消息来到，又没有信号量被激活的时候，就会被阻塞，具体实现可以去看MessagePumpForIO的WaitForWork方法。。。
不过这种阻塞是集中式的，可随时修改策略的，比起Channel直接阻塞在信号量上，停工的时间更短。。。

先将对Channel的操作放到Task中，将此Task放到IO线程队列里，让IO线程来处理即可。
当然，由于这种事情发生的太频繁，每次都人肉做一次颇为繁琐，于是有一个代理类，叫做ChannelProxy，来帮助你完成这一切。。。
当ChannelProxy的Send操作返回后，SyncChannel会把自己阻塞在一组信号量上，等待回包，直到永远或超时。

在Chrome中，IPC之间的通信消息，都是派生自IPC::Message类的。

消息的序列化
前不久读了Google Protocol Buffers的源码，是用在服务器端，用做内部机器通信协议的标准、代码生成工具和框架。它主要的思想是揉合了key/value的内容到二进制中，帮助生成更为灵活可靠的二进制协议。。。
在Chrome中，没有使用这套东西，而是用到了纯二进制流作为消息序列化的方式。我想这是由于应用场景不同使然。在服务端，我们更关心协议的稳定性，可扩展性，并且，涉及到的协议种类很多。但在一个Chrome中，消息的格式很统一，这方面没有扩展性和灵活性的需求，而在序列化上，虽然key/value的方式很好很强大，但是在Chrome中需要的不是灵活性而是精简性，因此宁可不用Protocol Buffers造好的轮子，而是另立炉灶，花了好一把力气提供了一套纯二进制的消息机制。。。

 

当需要创建一个新的RenderView的时候，Chrome会尝试进行选择或者是创建进程。
当达到这个上限后，你再开新的网站，Chrome会随机为你选择一个已有的进程，把这个网站对应的RenderView给扔进去。
Chrome并没有像我YY的一样做啥进程池之类的特殊机制，而是简单的履行有就创建、没有就销毁的策略。
Chrome的Render进程工作集调整，除了发生在tab切换（或新页面建立）的时候，还会发生在整个Chrome的idle事件触发后。