woai110120130的专栏

前面通过一些列文章，我们了解清楚了chromium的线程模型和ipc通信框架ipcz。接下来我们分析一下chromium的启动流程。本篇以browser进程启动为例进行分析。chromium的启动入口在chrome/app/chrome_exe_main_aura.cc中。这里面Aura是Chromium项目中用于窗口管理的底层框架。它负责管理用户界面的窗口和其他图形元素。Aura提供了一个跨平台的框架，用于构建Chromium浏览器的用户界面组件。

这里908-909行创建Message的时候指定的消息名称为internal::kChildProcess_BindServiceInterface_Name， 用于指示服务端调用哪个方法。Accept方法调用ChildProcessStubDispatch::Accept方法，第一个参数为sink_, 第二个参数为消息体。mojom::ChildProcess::Stub_ stub_, 也就是ChildProcessStub。我们看一下它的实现以及set_sink 方法。生成带c++代码如下。

MojoAddTriggerIpcz 函数顾名思义就是向trap添加一个触发器，用于注册trap 事件观察者，参数trap_handle 是用于指向MojoTrap的句柄，handle 是 portal的句柄，也就是添加的触发器针对与portal 上面的事件。Trap函数如果trap 关注的事件（conditions）没有满足，则会注册成功，否则返回IPCZ_RESULT_FAILED_PRECONDITION 表示前置条件不满足，满足的条件通过satisfied_condition_flags参数返回。

chromium通信系统-ipcz系统(六)-ipcz系统代码实现-跨Node通信-基础通信 一文我们分析了跨Node的基础通信过程。 a进程和b进程通信的过程。 但在程序中a进程将自己打开的一对portal中的一个portal传递给了b进程。由于篇幅问题这个过程我们并没有分析，这篇文章我们就来分析这个过程。代理路由的形成我们已经分析了基础通信过程。这里我们直接从RemoteRouterLink::AcceptParcel 函数开始分析端口的发送过程。142 void RemoteRouterLink

在chromium通信系统-ipcz系统(六)-ipcz系统代码实现-跨Node通信-基础通信 一文中我们分析了broker 和 nonbroker 通信的过程。本文我们来分析NonBroker 和NonBroker的通信过程，同样以单元测试为例子分析。mojo/core/invitation_unittest.cc 951 DEFINE_TEST_CLIENT(NonBrokerToNonBrokerHost) { 952 MojoHandle invitation = AcceptInvita

前面我们分析了Broker和NonBroker通信，也分析了NonBroker和NonBroker通信，这里我们分析一下Broker和Broker通信过程。我们直接一步到位，看NodeConnector的创建。当前节点是broker的情况下，对端节点也是broker，就是broker to broker请求，创建NodeConnectorForBrokerToBroker。uint32_t。

chromium通信系统-ipcz系统(二)-ipcz系统代码实现-同Node通信一文分析了同Node通信的场景。今天我们来分析一下跨Node通信的场景。我们以典型的broker 和非broker通信的场景来分析。mojo/core/invitation_unittest.cc 926 TEST_F(MAYBE_InvitationTest, NonBrokerToNonBroker) { 927 // Tests a non-broker inviting another non-broke

chromium ipzc 进程间通信基本概念介绍

chromium通信系统-mojo系统(一)-ipcz系统代码实现-同Node通信一文中我们分析了同Node通信的过程，在分析跨Node（跨进程）通信过程前，为了缩小篇幅，作为承上启下，我们先来分析一下Ipcz的通信信道和共享内存机制。我们在前面chromium通信系统-mojo系统(一)-ipcz系统基本概念一文介绍了NodeLink和RouterLink的概念，这两个概念都是比较上层，在一个操作系统中，两个进程要想通信，就要借助ipc机制。 如上图所示，RouterLink之间的通信要借助NodeL

ipcz driver层对应的对象基类为ObjectBase，ObjectBase 提供的方法包括： type方法返回对象的类型，FromHandle() 和 TakeFromHandle() 方法用于将IpczHandle() 转化为具体对象。ipcz层对应的对象基类为APIObject，APIObject 提供四个方法，FromHandle() 和 TakeFromHandle() 方法用于将IpczHandle() 转化为具体对象。系统层面的实现，主要是对Socket文件描述的包装。

mojo消息相关的宏人工比较难展开，所以让gpt帮忙展开了一下，写在这里bool NodeMessageListener::OnMessage(Message& message) { return DispatchMessage(message);}bool NodeMessageListener::OnTransportMessage( const DriverTransport::RawMessage& raw_message, const DriverTra

在chromium通信系统-mojo系统(一)-ipcz系统基本概念一文中我们介绍了ipcz的基本概念。 本章我们来通过代码分析它的实现。handle系统为了不对上层api暴露太多细节，实现解耦，也方便于传输，ipcz系统使用handle表示一个对象，handle类似于文件描述符，用IpczHandle类型表示ipcz系统内的一个对象。一个可以用IpczHandle 句柄表示的对象必须是APIObject子类。APIObject数据结构如下class APIObject : public RefCou

chromium线程模型分析

到这里，除了关闭的情景，线程池的方方面面也分析的差不多了。我觉得chromium的设计实在是太复杂，存在过度设计嫌疑。另外如果有协程就不必这么大费周折的去处理阻塞任务。也许是因为开发者对底层不太了解，也可能是很多历史包袱，才使得chromium的设计如此复杂吧。