MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
When shutting down a content process, we call `Close` on the
`IToplevelProtocol`. This causes the MessageChannel to be `Close`-ed,
which in turn sends a `GOODBYE_MESSAGE`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#2852
This message is intercepted on the I/O thread in the content process,
before any code is informed in content, and used to set the
`mChannelState` property to `ChannelClosing`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#1176
Once this state has been set, which is performed as soon as the
message is received, whether or not other messages have been processed
yet, no messages can be sent back to the parent process. This is
usually what causes the 'Too late to send/recv' message spam in the
console, as we're still trying to send messages at this time.
Usually this is fine - the message send fails, but we gracefully
recover, and the process begins shutting down like normal.
Unfortunately, child actor constructors currently have code
automatically generated in them which causes a process crash if the
send fails. As it's impossible for the main thread to know that the
channel has been closed ahead of time (due to this happening
out-of-band), we can then cause random content process crashes
during shutdown due to actor construction.
Unfortunately, we can't just destroy the actor, as our caller may
(and often do) depend on the actor reference they gave us still being valid
after calling Send*Constructor. Fortunately, if a message send failed, it means
we're in the process of being shut down.
This patch handles this by ignoring ctor send errors, and treating them like
messages which successfully were queued to send, but got lost due to the other
side hanging up. The actor will be gracefully destroyed in DestroySubtree when
its manager is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D12695
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
This will be useful as a basis for asynchronous actors which would like to exist
both when crossing the process boundary (managed by PContent), and when
displaying an in-process window.
Differential Revision: https://phabricator.services.mozilla.com/D4622
To create a more generic interface for interacting both within the main thread
of the parent process and between the parent and child processes, it would be
nice to support IPDL actors within the main thread of the parent process. This
requires the underlying MessageChannel actor to support intra-thread links.
This change adds support for intra-thread links to the underlying MessageChannel
object using ThreadLink, and an extra boolean flag.
Differential Revision: https://phabricator.services.mozilla.com/D4620
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used.
Depends on D8945
Differential Revision: https://phabricator.services.mozilla.com/D8946
--HG--
extra : moz-landing-system : lando
We can directly set environment variables for the child process on
all platforms now, instead of changing the parent's environment and
inheriting the changes. This simplifies memory management, but more
importantly it's necessary for thread safety to allow launching
processes from a thread pool.
Depends on D8944
Differential Revision: https://phabricator.services.mozilla.com/D8945
--HG--
extra : moz-landing-system : lando
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
