corysanin/tubestation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Backed out changeset 1890b6a3b3d2 (bug 1731667) for causing frequent address sanitizer failures.

Browse Source
This commit is contained in:
Iulian Moraru
2021-09-28 19:13:19 +03:00
parent 2c4e550afb
commit caf4295618
6 changed files with 21 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
toolkit/components/glean/api/src/ipc.rs
View File

@@ -13,7 +13,6 @@ use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::Mutex;
#[cfg(feature = "with_gecko")]
use {
std::convert::TryInto,
std::sync::atomic::{AtomicU32, Ordering},
xpcom::interfaces::nsIXULRuntime,
};
@@ -54,22 +53,14 @@ where
/// Thread-safe.
#[cfg(feature = "with_gecko")]
static PROCESS_TYPE: Lazy<AtomicU32> = Lazy::new(|| {
extern "C" {
fn FOG_GetProcessType() -> i32;
if let Some(appinfo) = xpcom::services::get_XULRuntime() {
let mut process_type = nsIXULRuntime::PROCESS_TYPE_DEFAULT as u32;
let rv = unsafe { appinfo.GetProcessType(&mut process_type) };
if rv.succeeded() {
return AtomicU32::new(process_type);
}
}
// SAFETY NOTE: Safe because it returns a primitive by value.
let process_type = unsafe { FOG_GetProcessType() };
// It's impossible for i32 to overflow u32, but maybe someone got clever
// and introduced a negative process type constant. Default to parent.
let process_type = process_type
.try_into()
.unwrap_or(nsIXULRuntime::PROCESS_TYPE_DEFAULT as u32);
// We don't have process-specific init locations outside of the main
// process, so we introduce this side-effect to a global static init.
// This is the absolute first time we decide which process type we're
// treating this process as, so this is the earliest we can do this.
register_process_shutdown(process_type);
AtomicU32::new(process_type)
AtomicU32::new(nsIXULRuntime::PROCESS_TYPE_DEFAULT as u32)
});
#[cfg(feature = "with_gecko")]
@@ -77,33 +68,6 @@ pub fn need_ipc() -> bool {
PROCESS_TYPE.load(Ordering::Relaxed) != nsIXULRuntime::PROCESS_TYPE_DEFAULT as u32
}
/// The first time we're used in a process,
/// we'll need to start thinking about cleanup.
///
/// Please only call once per process.
/// Multiple calls may register multiple handlers.
#[cfg(feature = "with_gecko")]
fn register_process_shutdown(process_type: u32) {
match process_type as i64 {
nsIXULRuntime::PROCESS_TYPE_DEFAULT => {
// Parent process shutdown is handled by the FOG XPCOM Singleton.
}
nsIXULRuntime::PROCESS_TYPE_CONTENT => {
// Content child shutdown is in C++ for access to RunOnShutdown().
extern "C" {
fn FOG_RegisterContentChildShutdown();
}
unsafe {
FOG_RegisterContentChildShutdown();
};
}
_ => {
// We don't yet support other process types.
log::error!("Process type {} tried to use FOG, but isn't supported! (Process type constants are in nsIXULRuntime.rs)", process_type);
}
}
}
/// An RAII that, on drop, restores the value used to determine whether FOG
/// needs IPC. Used in tests.
/// ```rust,ignore

72
toolkit/components/glean/docs/dev/ipc.md
View File

@@ -69,8 +69,7 @@ if (XRE_GetProcessType() == GeckoProcessType_Default) {
### 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,
and during orderly shutdowns.
FOG will try its best to schedule opportunistically in idle moments.
There are a few cases where we provide more firm guarantees:
@@ -86,22 +85,13 @@ await FOG.testFlushAllChildren();
```
See [the test documentation](testing.md) for more details on testing.
#### Pings
We do not guarantee that non-main-process data has made it into a specific ping.
#### Built-in Pings
[Built-in pings](https://mozilla.github.io/glean/book/user/pings/index.html)
are submitted by the Rust Glean SDK at times FOG doesn't directly control,
so there may be data not present in the parent process when a built-in ping is submitted.
We don't anticipate this causing a problem since child-process data that
"misses" a given ping will be included in the next one.
will send only after all metric values from all child processes have been collected.
At this time,
[Custom Pings](https://mozilla.github.io/glean/book/user/pings/custom.html)
must be sent in the parent process and have no mechanism
to schedule their submission for after child-process data arrives in the parent process.
[bug 1732118](https://bugzilla.mozilla.org/show_bug.cgi?id=1732118)
tracks the addition of such a mechanism or guarantee.
We cannot at this time provide the same guarantee for
[Custom Pings](https://mozilla.github.io/glean/book/user/pings/custom.html).
#### Shutdown
@@ -111,9 +101,13 @@ may result in child process data being lost.
### Mechanics
The rough design is that the parent process can request an immediate flush of pending data,
and each child process can decide to flush its pending data whenever it wishes.
The former is via `FlushFOGData() returns (ByteBuf)` and the latter via `FOGData(ByteBuf)`.
At present
(see [bug 1641989](https://bugzilla.mozilla.org/show_bug.cgi?id=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,
@@ -121,45 +115,3 @@ then given back to `bincode` in Rust on the Parent.
Rust is then responsible for turning the pending data into
[metric API](../user/api.md) calls on the metrics in the parent process.
#### Supported Process Types
FOG supports messaging between the following types of child process and the parent process:
* content children (via `PContent`
(for now. See [bug 1641989](https://bugzilla.mozilla.org/show_bug.cgi?id=1641989))
See
[the process model docs](../../../../dom/ipc/process_model.html)
for more information about what that means.
### Adding Support for a new Process Type
Adding support for a new process type is a matter of extending the two messages
mentioned above in "Mechanics" to another process type's protocol (ipdl file).
1. Add two messages to the appropriate sections in `P<ProcessType>.ipdl`
* (( **Note:** `PGPU` _should_ be the only ipdl where `parent`
means the non-parent/-main/-UI process,
but double-check that you get this correct.))
* Add `async FOGData(ByteBuf&& aBuf);` to the parent/main/UI process side of things
(most often `parent:`).
* Add `async FlushFOGData() returns (ByteBuf buf);` to the non-parent/-main/-UI side
(most often `child:`).
2. Implement the protocol endpoints in `P<ProcessType>{Child|Parent}.{h|cpp}`
* The message added to the `parent: ` section goes in
`P<ProcessType>Parent.{h|cpp}` and vice versa.
3. Add to `FOGIPC.cpp`'s `FlushAllChildData` code that
1. Enumerates all processes of the newly-supported type (there may only be one),
2. Calls `SendFlushFOGData on each, and
3. Adds the resulting promise to the array.
4. Add to `FOGIPC.cpp`'s `SendFOGData` the correct `GeckoProcessType_*`
enum value, and appropriate code for getting the parent process singleton and calling
`SendFOGData` on it.
5. Add to the fog crate's `register_process_shutdown` function
handling for at-shutdown flushing of IPC data.
If this isn't added, we will log (but not panic)
on the first use of Glean APIs on an unsupported process type.
* "Handling" might be an empty block with a comment explaining where to find it
(like how `PROCESS_TYPE_DEFAULT` is handled)
* Or it might be custom code
(like `PROCESS_TYPE_CONTENT`'s)

3
toolkit/components/glean/docs/dev/testing.md
View File

@@ -28,13 +28,10 @@ To turn on logging for FOG, use any of the following:
* `logging.fog::*` to `5`
* `logging.glean::*` to `5`
* `logging.glean_core::*` to `5`
* `logging.config.clear_on_startup` to `false` (or all these prefs will be cleared on startup)
For more information on logging in Firefox Desktop, see the
[Gecko Logging docs](https://developer.mozilla.org/docs/Mozilla/Developer_guide/Gecko_Logging).
**Note:** At present Rust logging in non-main processes just doesn't work.
## `about:glean`
`about:glean` is a page in a running Firefox that allows you to

28
toolkit/components/glean/ipc/Support.cpp
View File

@@ -1,28 +0,0 @@
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2; -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
// This file is for support functions for the Rust IPC module.
// Some information just isn't available to Rust and must be made available over
// FFI.
#include "FOGIPC.h"
#include "mozilla/ClearOnShutdown.h"
using mozilla::RunOnShutdown;
using mozilla::ShutdownPhase;
using mozilla::glean::FlushFOGData;
using mozilla::glean::SendFOGData;
using mozilla::ipc::ByteBuf;
extern "C" {
void FOG_RegisterContentChildShutdown() {
RunOnShutdown(
[] {
FlushFOGData([](ByteBuf&& aBuf) { SendFOGData(std::move(aBuf)); });
},
ShutdownPhase::AppShutdownConfirmed);
}
int FOG_GetProcessType() { return XRE_GetProcessType(); }
}

1
toolkit/components/glean/moz.build
View File

@@ -80,7 +80,6 @@ UNIFIED_SOURCES += [
"bindings/private/TimingDistribution.cpp",
"bindings/private/Uuid.cpp",
"ipc/FOGIPC.cpp",
"ipc/Support.cpp",
]
SOURCES += [

7
toolkit/components/glean/xpcom/FOG.cpp
View File

@@ -135,12 +135,9 @@ FOG::Observe(nsISupports* aSubject, const char* aTopic, const char16_t* aData) {
// On idle, opportunistically flush child process data to the parent,
// then persist ping-lifetime data to the db.
if (!strcmp(aTopic, OBSERVER_TOPIC_IDLE)) {
#ifdef MOZ_GLEAN_ANDROID
glean::FlushAndUseFOGData();
#else
glean::FlushAndUseFOGData()->Then(
GetCurrentSerialEventTarget(), __func__,
[]() { Unused << glean::impl::fog_persist_ping_lifetime_data(); });
#ifndef MOZ_GLEAN_ANDROID
Unused << glean::impl::fog_persist_ping_lifetime_data();
#endif
}