Most users of JSONWriter want to fill a string, so instead of having all these
similar implementations, we now have central reusable implementations:
- JSONStringWriteFunc contains a string and writes to it.
- JSONStringRefWriteFunc references a string and writes to it. This is most
useful when the string already exists somewhere, or needs to be returned from
a function (so we avoid another conversion when returning).
Differential Revision: https://phabricator.services.mozilla.com/D154618
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
Most users of JSONWriter want to fill a string, so instead of having all these
similar implementations, we now have central reusable implementations:
- JSONStringWriteFunc contains a string and writes to it.
- JSONStringRefWriteFunc references a string and writes to it. This is most
useful when the string already exists somewhere, or needs to be returned from
a function (so we avoid another conversion when returning).
Depends on D154617
Differential Revision: https://phabricator.services.mozilla.com/D154618
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
Given that libevent's signal handling code is known to have race
conditions, and there are fundamental issues that make it hard to fix
upstream, and previous patches have removed our last usage of it, we
should assert that it's no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D141312
The function DidProcessCrash is now dead code. Before the ProcessWatcher
rewrite, its return value (i.e., whether the process crashed) was never
used, so effectively its only purpose was to make it harder to understand
where the waitpid calls were happening.
Differential Revision: https://phabricator.services.mozilla.com/D141310
This patch rewrites the Unix backend of ProcessWatcher for two reasons:
1. To remove the use of libevent's signal handling, which has concurrency
bugs that can't be easily fixed upstream (see Bugzilla for details)
2. To simplify the code in general; in particular, the new version has one
place where the process and its exit status are consumed from the OS
The new implementation uses the same pipe-to-self technique as libevent
(and which we use elsewhere) to deal with async signal safety. Unlike
the previous version, there is a single object which manages all
monitored child processes rather than one each. (Previously, this
multiplexing was done inside libevent.)
Differential Revision: https://phabricator.services.mozilla.com/D141309
This won't be used for any security or routing purposes, but can be useful for
debugging. It will be used in the future by the profiler to correlate sent and
received message events across processes.
Differential Revision: https://phabricator.services.mozilla.com/D153621
These constructors are unnecessary and can be defined with a `using` statement,
making it easier to change all constructors simultaneously.
Differential Revision: https://phabricator.services.mozilla.com/D153620
This improves consistency with the child process case, and will make it easier
to attach additional state without needing to thread it through every child
process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153619
This type is also used in other places to start non-initial actors, and will
allow us to attach additional state more easily without needing to thread it
through every child process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153618
Previously this code read the atomic rather than the cached value (which
was unused). This is inherently racy as the atomic is updated on a
different thread than the read happened on.
Differential Revision: https://phabricator.services.mozilla.com/D153617
Currently, Subprocess.jsm on Unix uses js-ctypes to call `posix_spawn`.
This has some issues, primarily that file descriptors are inherited by
the child process unless explicitly opted-out, which unfortunately a lot
of code doesn't do. This patch changes it to use IPC process launching,
where fd inheritance is opt-in, by:
1. Extending `base::LaunchApp` to handle a few features that Subprocess
needs (setting the process's working directory, specifying the full
environment, and the macOS `disclaim` flag)
2. Adding a WebIDL method to `IOUtils` to expose that function to JS
(currently Unix-only; Windows could also be supported but it would
probably want to use a different IDL type for strings, given that the
OS APIs use 16-bit code units).
3. Replacing the part of Subprocess that invokes `posix_spawn` (and
related functions) by calling that method; the rest of Subprocess's
machinery to manage pipes and I/O is unchanged. (The Windows backend
is also unchanged; I'm not aware of any functional issues there.)
This results in some dead code, which is removed.
Differential Revision: https://phabricator.services.mozilla.com/D152336
Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to
not be visible to the IPDL compiler as it is only serialized within an opaque
type included with `using`. If that happens, it would cause the construction of
the Shmem to fail on the other side, in a hard to diagnose manner. This changes
the logic to always allow any actor to manage shmems, to make it more in line
with the `AllocShmem` method being directly declared on IProtocol.
This specifically caused issues after this patch stack with PContent, which no
longer has any shmem arguments visible to IPDL after these changes, but still
is used as a manager for Shmems included in some messages.
Differential Revision: https://phabricator.services.mozilla.com/D151855
Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to
not be visible to the IPDL compiler as it is only serialized within an opaque
type included with `using`. If that happens, it would cause the construction of
the Shmem to fail on the other side, in a hard to diagnose manner. This changes
the logic to always allow any actor to manage shmems, to make it more in line
with the `AllocShmem` method being directly declared on IProtocol.
This specifically caused issues after this patch stack with PContent, which no
longer has any shmem arguments visible to IPDL after these changes, but still
is used as a manager for Shmems included in some messages.
Differential Revision: https://phabricator.services.mozilla.com/D151855
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
This means we can include these files in other binaries when we need earlier
access to the process type and use consistent code.
Differential Revision: https://phabricator.services.mozilla.com/D152198
We were already turning off Mesa's shader cache in the RDD process,
because it's not useful given that we're only using video codec
acceleration and moving images around, and it does a few things related
to trying to access the cache that the sandbox would have to accomodate.
This patch does the equivalent thing for the nvidia proprietary driver;
we don't support it for media codec acceleration, but it can still be
loaded in that process (e.g., on multi-GPU systems) and it's trying to
call `statfs` on startup which may be related.
Differential Revision: https://phabricator.services.mozilla.com/D152932
Instead of using the public member type `PrivateIPDLCaller` to
restrict access to certain `Shmem` member functions, make them
`private`, and designated `IProtocol` and `ITopLevelProtocol` as
friends of `Shmem`.
Differential Revision: https://phabricator.services.mozilla.com/D151952
This type is inspired by the Chromium BigBuffer type, and acts as a type which
intelligently either allocates a shared memory region or in-memory buffer based
on the size of the payload. The current threshold is 64k bytes, and it can be
somewhat cheaply transferred over IPC.
This is intended to be used in places where we currently create a basic `Shmem`
to transfer a potentially large block of bytes over IPC.
Differential Revision: https://phabricator.services.mozilla.com/D151851
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519