

Inter-process Communication (IPC)
source link: https://firefox-source-docs.mozilla.org/toolkit/components/glean/dev/ipc.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Inter-process Communication (IPC)¶
Firefox Desktop is a multi-process desktop application. Code requiring instrumentation may be on any of its processes, so FOG provide facilities to do just that.
Design¶
The IPC Design of FOG was worked out in bug 1618253.
It centred around a few specific concepts:
Forbidding Non-Commutative Operations¶
Because we cannot nicely impose a canonical ordering of metric operations across all processes, FOG forbids non-commutative metric operations in some circumstances.
For example,
Add()
-ing to a Counter metric works from multiple processes because the order doesn’t matter.
However, given a String metric being Set()
from multiple processes simultaneously,
which value should it take?
This ambiguity is not a good foundation to build trust on, so we forbid setting a String metric from multiple processes.
List of Forbidden Operations¶
Boolean’s
set
(this is the metric type’s only operation)Labeled Boolean’s
set
(this is the metric type’s only operation)String’s
set
(this is the metric type’s only operation)Labeled String’s
set
(this is the metric type’s only operation)String List’s
set
add
is permitted (order and uniqueness are not guaranteed)
Timespan’s
start
,stop
, andcancel
(these are the metric type’s only operations)UUID’s
set
andgenerateAndSet
(these are the metric type’s only operations)Datetime’s
set
(this is the metric type’s only operation)Quantity’s
set
(this is the metric type’s only operation)
This list may grow over time as new metric types are added. If there’s an operation/metric type on this list that you need to use in a non-parent process, please reach out on the #glean channel and we’ll help you out.
Process Agnosticism¶
For metric types that can be used cross-process, FOG provides no facility for identifying which process the instrumentation is on.
What this means is that if you accumulate to a Timing Distribution in multiple processes, all the samples from all the processes will be combined in the same metric.
If you wish to distinguish samples from different process types, you will need multiple metrics and inline code to select the proper one for the given process. For example:
if (XRE_GetProcessType() == GeckoProcessType_Default) { mozilla::glean::performance::cache_size.Accumulate(numBytes / 1024); } else { mozilla::glean::performance::non_main_process_cache_size.Accumulate(numBytes / 1024); }
Scheduling¶
FOG makes no guarantee about when non-main-process metric values are sent across IPC. FOG will try its best to schedule opportunistically in idle moments.
There are a few cases where we provide more firm guarantees:
Tests¶
There are test-only APIs in Rust, C++, and Javascript.
These do not await a flush of child process metric values.
You can use the test-only method testFlushAllChildren
on the FOG
XPCOM component to await child data’s arrival:
let FOG = Cc["@mozilla.org/toolkit/glean;1"].createInstance(Ci.nsIFOG); await FOG.testFlushAllChildren();
See the test documentation for more details on testing.
Built-in Pings¶
Built-in pings will send only after all metric values from all child processes have been collected.
We cannot at this time provide the same guarantee for Custom Pings.
Shutdown¶
We will make a best effort during an orderly shutdown to flush all pending data in child processes. This means a disorderly shutdown (usually a crash) may result in child process data being lost.
Mechanics¶
At present (see bug 1641989) FOG uses messages on the PContent protocol. This enables communication between content child processes and the parent process.
The rough design is that the Parent can request an immediate flush of pending data, and each Child can decide to flush its pending data whenever it wishes.
Pending Data is a buffer of bytes generated by bincode
in Rust in the Child,
handed off to C++, passed over IPC,
then given back to bincode
in Rust on the Parent.
Rust is then responsible for turning the pending data into metric API calls on the metrics in the parent process.
Recommend
-
49
AndLinker:Android 上的 IPC 库
-
79
IPC就是跨进程通信。什么是进程呢?它一般指的是一个程序或应用。一个进程可以有多个线程,所以进程和线程是包括与被包括的关系。在Android里主线程就是UI线程,如果有很多任务都放在主线程里,就容易造成ANR,解决办法就是多开线程。...
-
13
作者:zzssdd2 E-mail:[email protected] 一、应用简介 在RTOS的应用开发中,信号量也是经常使用到的一种用于多任务之间信...
-
5
Inter-Process CommunicationIn many ways, the story of Apple has been about fusing together technologies through happy accidents of history to create something better than before: OS X as a hybrid of MacOS & NeXTSTEP. Objective-C as the co...
-
15
macOS IPC Study Notes
-
11
The PMCs of EC2: Measuring IPC 04 May 2017 IPC and LLC loads with a scaling workload Perfo...
-
16
ipc-bench Some very crude IPC benchmarks. ping-pong latency benchmarks: pipes unix domain sockets tcp sockets throughput benchmarks: pipes unix domain sockets
-
8
Examining JavaScript Inter-Process Communication in Firefox Frederik Braun Apri...
-
4
@authorityjoelOlusegun Joel TitusPh.D. Candidate at Universitat Pompeu Fabra. Blockchain and web3 technology, Audio platforms researcher.
-
6
What is the Inter-Blockchain Communication Protocol (IBC)?NotificationsHappy Weekend, enjoy these top stories from this week, Deglorifying CEOs, Spawn of the Stars, and more 💚...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK