Inter-process Communication (IPC)
Inter-process Communication (IPC)
OverviewChromium has a multi-process architecture which means that we have a lot of processes communicating with each other. Our main inter-process communication primitive is the named pipe. On Linux & OS X, we use a socketpair(). A named pipe is allocated for each renderer process for communication with the browser process. The pipes are used in asynchronous mode to ensure that neither end is blocked waiting for the other. For advice on how to write safe IPC endpoints, please see Security Tips for IPC. IPC in the browserWithin the browser, communication with the renderers is done in a separate I/O thread. Messages to and from the views then have to be proxied over to the main thread using a IPC in the rendererEach renderer also has a thread that manages communication (in this case, the main thread), with the rendering and most processing happening on another thread (see the diagram in multi-process architecture). Most messages are sent from the browser to the WebKit thread through the main renderer thread and vice-versa. This extra thread is to support synchronous renderer-to-browser messages (see "Synchronous messages" below). MessagesTypes of messagesWe have two primary types of messages: "routed" and "control." Control messages are handled by the class that created the pipe. Sometimes that class will allow others to received message by having a MessageRouter object that other listeners can register with and received "routed" messages sent with their unique (per pipe) id. For example, when rendering, control messages are not specific to a given view and will be handled by the Routed messages have historically been used to get messages to a specific RenderViewHost. However, technically any class can receive routed messages by using RenderProcessHost::GetNextRoutingID and registering itself with RenderProcessHost::AddRoute. Currently both RenderViewHost and RenderFrameHost instances have their own routing IDs. Independent of the message type is whether the message is sent from the browser to the renderer, or from the renderer to the browser. Messages related to a document's frame sent from the browser to the renderer are called Plugins also have separate processes. Like the render messages, there are The same organization applies for other groups of messages exchanged between the browser and the renderer, as for View and ViewHost labeled messages exchanged between RenderViewHost and RenderView, defined in view_messages.h. Declaring messagesSpecial macros are used to declare messages. To declare a routed message from the renderer to the browser (e.g. a FrameHost message specific to a frame) that contains a URL and an integer as an argument, write: IPC_MESSAGE_ROUTED2(FrameHostMsg_MyMessage, GURL, int) To declare a control message from the browser to the renderer (e.g. a Frame message not specific to a frame) that contains no parameters, write: IPC_MESSAGE_CONTROL0(FrameMsg_MyMessage) Pickling valuesParameters are serialized and de-serialized to message bodies using the Sometimes, a message has too many values to be reasonably put in a message. In this case, we define a separate structure to hold the values. For example, for the Sending messagesYou send messages through "channels" (see below). In the browser, the Messages are sent by pointer and will be deleted by the IPC layer after they are dispatched. Therefore, once you can find the appropriate Send(new ViewMsg_StopFinding(routing_id_)); Notice that you must specify the routing ID in order for the message to be routed to the correct View/ViewHost on the receiving end. Both the Handling messagesMessages are handled by implementing the MyClass::OnMessageReceived(const IPC::Message& message) { You can also use Other macros:
IPC_MESSAGE_FORWARD(ViewHostMsg_MyMessage, some_object_pointer, SomeObject::OnMyMessage)
IPC_MESSAGE_HANDLER_GENERIC(ViewHostMsg_MyMessage, printf("Hello, world, I got the message.")) Security considerationsSecurity bugs in IPC can have nasty consequences (file theft, sandbox escapes, remote code execution). Check out our security for IPC document for tips on how to avoid common pitfalls. Channels
Channels are not thread safe. We often want to send messages using a channel on another thread. For example, when the UI thread wants to send a message, it must go through the I/O thread. For this, we use a Synchronous messagesSome messages should be synchronous from the renderer's perspective. This happens mostly when there is a WebKit call to us that is supposed to return something, but that we must do in the browser. Examples of this type of messages are spell-checking and getting the cookies for JavaScript. Synchronous browser-to-renderer IPC is disallowed to prevent blocking the user-interface on a potentially flaky renderer. Danger: Do not handle any synchronous messages in the UI thread! You must handle them only in the I/O thread. Otherwise, the application might deadlock because plug-ins require synchronous painting from the UI thread, and these will be blocked when the renderer is waiting for synchronous messages from the browser. Declaring synchronous messagesSynchronous messages are declared using the IPC_SYNC_MESSAGE_CONTROL2_1(SomeMessage, // Message name Likewise, you can also have messages that are routed to the view in which case you would replace "control" with "routed" to get Issuing synchronous messagesWhen the WebKit thread issues a synchronous IPC request, the request object (derived from While the WebKit thread is waiting for the synchronous reply, the main thread is still receiving messages from the browser process. These messages will be added to the queue of the WebKit thread for processing when it wakes up. When the synchronous message reply is received, the thread will be un-blocked. Note that this means that the synchronous message reply can be processed out-of-order. Synchronous messages are sent the same way normal messages are, with output parameters being given to the constructor. For example: const GURL input_param("http://www.google.com/"); Handling synchronous messagesSynchronous messages and asynchronous messages use the same IPC_MESSAGE_HANDLER(MyMessage, OnMyMessage) to the void RenderProcessHost::OnMyMessage(GURL input_param, std::string* result) { Converting message type to a message nameIf you get a crash and you have the message type you can convert this to a message name. The message type will be 32-bit value, the high 16-bits are the class and the low 16-bits are the id. The class is based on the enums in ipc/ipc_message_start.h, the id is based on the line number in the file that defines the message. This means that you need to get the exact revision of Chromium in order to accurately get the message name. Example of this in 554011 was 0x1c0098 at Chromium revision ad0950c1ac32ef02b0b0133ebac2a0fa4771cf20. That's class 0x1c which is line 40 which matches ChildProcessMsgStart. ChildProcessMsgStart messages are in content/common/child_process_messages.h and the IPC will be on line 0x98 or line 152 which is ChildProcessHostMsg_ChildHistogramData. This technique is particularly useful if you are dealing with crashes caused by content::RenderProcessHostImpl::OnBadMessageReceived |
Inter-process Communication (IPC)的更多相关文章
- The Signals Of Process Communication
在之前大概的概述了进程之间的通信,下面笔者具体述说一下进程通信中最古老的一种通信方式之一---信号(Signals ),信号是用户进程之间通信和同步的一种原始机制,操作系统通过信号来通知进程系统中发生 ...
- 60年代进程 80年代线程 IPC How the Java Virtual Machine (JVM) Works
小结: 1. To facilitate communication between processes, most operating systems support Inter Process C ...
- 快速入门系列--WCF--01基础概念
转眼微软的WCF已走过十个年头,它是微软通信框架的集大成者,将之前微软所有的通信框架进行了整合,提供了统一的应用方式.记得从自己最开始做MFC时,就使用过Named Pipe命名管道,之后做Winfo ...
- 【翻译二】java--并发之进程与线程
Processes and Threads In concurrent programming, there are two basic units of execution: processes a ...
- Concurrency Series 1
Difference between Processes and Threads Processes A process has a self-contained execution environm ...
- 再见WCF
转眼微软的WCF已走过十个年头,它是微软通信框架的集大成者,将之前微软所有的通信框架进行了整合,提供了统一的应用方式.记得从自己最开始做MFC时,就使用过Named Pipe命名管道,之后做Winfo ...
- java 并发官方教程
http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html Concurrency Computer users t ...
- Spring Cloud构建微服务架构(二)服务消费者
Netflix Ribbon is an Inter Process Communication (IPC) cloud library. Ribbon primarily provides clie ...
- 4.namespace
命名空间( namespace)是 Linux 内核的一个强大特性,为容器虚拟化的实现带来极大便 利. 利用这一特性,每个容器都可以拥有自己单独的命名空间,运行在其中的应用都像是在 独立的操作系统环境 ...
随机推荐
- 平凡主丛上的Yang-Mills理论
本文是复旦大学由丁青教授的暑期课程“Yang-Mills理论的几何及其应用”所作笔记,会有少许修正. 所需基础: 多元微积分学 微分方程(常微分方程,数学物理方程) 曲线曲面论(初等微分几何) 以下是 ...
- Linux用户与用户组
Linux用户与用户组 Linux系统是一个多用户多任务的分时操作系统,任何一个要使用系统资源的用户,都必须首先向系统管理员申请一个账号,然后以这个账号的身份进入系统. 用户的账号一方面可以帮助系统管 ...
- [React] React.PureComponent
React.PureComponent is similar to React.Component. The difference between them is that React.Compone ...
- iOS:界面上下空出黑条
启动图没有加入完整造成
- 手机Android音视频採集与直播推送,实现单兵、移动监控类应用
最新手机採集推送直播监控以及EasyDarwin开源流媒体平台的版本号及代码: EasyDarwin 开源流媒体云平台:https://github.com/easydarwin EasyClient ...
- 使用深度学习检测DGA(域名生成算法)——LSTM的输入数据本质上还是词袋模型
from:http://www.freebuf.com/articles/network/139697.html DGA(域名生成算法)是一种利用随机字符来生成C&C域名,从而逃避域名黑名单检 ...
- linux中的raid
参考文档 http://www.cnblogs.com/ivictor/p/6099807.html 制作raid5 http://blog.51cto.com/11134648/2103384 RA ...
- react --- 路由传参的几种方式
1.params 优势 : 刷新地址栏,参数依然存在缺点:只能传字符串,并且,如果传的值太多的话,url会变得长而丑陋. 2.query 优势:传参优雅,传递参数可传对象:缺点:刷新地址栏,参数丢失 ...
- ScrollView嵌套GridView不显示顶部
/* * scrollView中嵌套GridView不能显示头部 * * 方案①:scrollView.smoothScrollTo(0, 0); * * ...
- Linux安装多功能词典GoldenDict
Linux安装多功能词典GoldenDict 活腿肠 2017.08.01 20:52* 字数 671 阅读 1555评论 0喜欢 2 Goldendict 简介 GoldenDict是一种开源的辞典 ...