This includes deleting several unused functions. Our own code does a better job
of using the preferred platform APIs for random numbers.
Differential Revision: https://phabricator.services.mozilla.com/D18120
--HG--
extra : moz-landing-system : lando
ProcessTypeRequiresWinEventHook was added when attempting to turn on win32k
lockdown for GMP processes. Having a less specific, but globally accessible,
function will make it more useful while applying win32k lockdown to other
process types.
Before this patch, IPCStream was an union containing IPCRemoteSteam or an
InputStreamParamsWithFds. Now InputStreamParamsWithFds is renamed IPCStream and
IPCRemoteSteam is one of the possible InputStreamParams structs.
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
This is handy when performing process swaps, as it provides useful & important
information to parent-process callers.
Depends on D15608
Differential Revision: https://phabricator.services.mozilla.com/D15609
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Avoiding handle duplication for certain kinds of processes and allowing
it for everything else seems to be what we're already doing, so let's
make it easier to add new process types with that scheme in mind.
The command-line parameter used by nsEmbedFunctions.cpp is turned into
an nsIFile, and then said nsIFile is never used. Its last use was
deleted in bug 1407693, where we reworked how extra annotations were
done.
Android mercilessly kills the parent in low memory situations, and we
don't want that to trigger a crash when the child is abruptly
disconnected.
Differential Revision: https://phabricator.services.mozilla.com/D16234
--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. (Or, in the Web Replay
middleman process, where there isn't enough of XPCOM for any of this,
launching the actual content processes remains on the I/O thread.)
Depends on D15886
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