This simplifies the logic around MessageTask's lifecycle to make
ownership as clear as possible and reduce the number of redundant
checks.
This new change no longer clears the mChannel member when the
MessageTask is disconnected, instead relying on isInList() to check
whether the MessageTask is still in the channel's mPending list. This is
already being automatically managed as the mPending list is modified,
and should avoid potential usage mistakes.
Differential Revision: https://phabricator.services.mozilla.com/D123140
This change instead recovers from unhandled special messages by reporting a
normal IPC error, which should be handled using the normal IPC error
mechanisms.
Depends on D123148
Differential Revision: https://phabricator.services.mozilla.com/D123149
When this change was first implemented, it ignored dead actors for all types of
messages, but for messages with replies they cannot be ignored, as a reply must
be sent. This should fix that oversight.
Differential Revision: https://phabricator.services.mozilla.com/D123148
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
rlbox_wasm2c_sandbox was adjusted to avoid using LoadLibraryA (rejected by
build/clang-plugin/LoadLibraryUsageChecker.cpp), so we adjust
GetSandboxedRLBoxPath (which is used to feed it) to return an UTF-16
string on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D123025
Memory for memfd files isn't subject to any file size limit, unlike
named files in /dev/shm, and is documented as being handled similarly
to anonymous mmap for accounting / resource management purposes.
Therefore, there isn't any need to pre-commit the memory with
posix_fallocate in that case.
Differential Revision: https://phabricator.services.mozilla.com/D121818
This merges the cases for posix_fallocate being unavailable at build
time and being rejected dynamically by the OS (some don't support
it with their implementation of POSIX shm), to make it simple to
dynamically opt out in the memfd case.
Differential Revision: https://phabricator.services.mozilla.com/D121817
This lets the idle scheduler know that we've initiated a GC that we didn't
ask its permission for. Eg the JS engine hit a threshold. It now uses this
info when scheduling GCs for other processes.
Differential Revision: https://phabricator.services.mozilla.com/D120831
This patch also:
* adds an assertion to KillGCRunner() to ensure it's never killed if
needed, now that there are more calls to KillGCRunner(), some calls have
been moved eg in nsJSEnvironment so as not to kill the runner a little
later and keep the assertions happy.
* IdleSchedulerChild will decline a request for a GC if there's already a
request in flight.
* CCGCScheduler will check if a GC is already in progress when handling the
parents' response to a GC request.
Differential Revision: https://phabricator.services.mozilla.com/D120830
`mscom::ProcessRuntime` supports multiple instances because Reasons (TM).
To make this happen, we store some information in `mozglue` that enforces
serialization between instances and also informs an instance as to whether
any other instances have successfully completed initialization.
Unfortunately it is possible for us to encounter situations where one instance
manages to *partially* but not *completely* finish initialization. Since our
shared information is currently a simple `bool`, we cannot really capture this
case.
Furthermore, APIs such as `CoInitializeSecurity` will actually fail if called
again after previous activity, so we should guard against multiple invocations
within the same process.
To improve this situation, I'd like to replace the shared `bool` with a typed
enum that can provide finer-grained information as to how far a previous
instance actually managed to get.
Differential Revision: https://phabricator.services.mozilla.com/D121672
This should make the logic around clearing a MessageChannel more obviously
correct by holding the mutex when accessing fields which are traditionally
guarded by the mutex. These lock calls shouldn't introduce performance issues
as the lock should be uncontended.
Differential Revision: https://phabricator.services.mozilla.com/D119354
This state was only used by the ProcessLink MessageLink implementation, and no
longer exists with the new PortLink implementation, so can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D119353
Now that PortLink is the only MessageLink implementation, it is no longer
necessary to support sharing a single `RefCountedMonitor` between multiple
MessageChannels, meaning that we can construct the monitor directly in the
`MessageChannel` constructor. The monitor still needs to be refcounted due to
being used by the PortLink as part of the listener implementation.
Differential Revision: https://phabricator.services.mozilla.com/D119350
This makes things generally more clear, and avoids a long list of initializers
in the MessageChannel constructor. In addition, some fields which are never
modified are marked as `const`.
Differential Revision: https://phabricator.services.mozilla.com/D119349
We will only run the processes in CET compatible modules only mode when not
using the JIT code. So marking xul.dll as compatible should be OK.
Differential Revision: https://phabricator.services.mozilla.com/D117551
We use the process handle returned from `CreateProcess` to derive
another handle with more permissions, but the original handle is never
closed. This bug appears to be fairly old: it existed before this code
was converted to use MozPromise.
Currently we provide the original handle to external consumers of the
launch promise; this patch resolves the promise with the privileged
handle instead and closes the original one. (One consumer uses the
handle only to obtain the pid, and the rest don't use it at all, so this
shouldn't change anything.)
As a related cleanup, `ProcessLaunchPromise` is now exclusive (because
it's resolved with resources which are consumed) and no longer declared
in the header file (because it's used only internally).
Differential Revision: https://phabricator.services.mozilla.com/D119820
After looking through the methods which have this assertion, I couldn't
find any examples of places where not having a specific "link thread"
sequence would cause any issues. I think these assertions can and should
be removed.
The main change required by this was to remove the `!NS_IsMainThread()`
assertion from the SchedulerGroup listener. Due to how callbacks work,
it would be possible for a vsync message to be detected by a
MessageChannel from the main thread if it was sent before the channel
was bound. I don't believe that this change should cause any issues.
Differential Revision: https://phabricator.services.mozilla.com/D119348
This change stores a generated nsID directly on the LoadInfo, rather
than the full SandboxedLoadingPrincipal. This allows for the sandboxed
principal to be constructed from GetChannelResultPrincipal using the
unsandboxed result principal as a precursor, rather than the loading
principal.
The nsID is reset by HttpChannelBase whenever a non-internal redirect
occurs to reduce the chance of multiple null result principals during a
redirect with the same nsID, but different precursors.
Depends on D119692
Differential Revision: https://phabricator.services.mozilla.com/D119693
Tetsuharu Ohzeki
Kershaw Chang
Nika Layzell
Matt Woodrow
Butkovits Atila
Andi-Bogdan Postelnicu
Mike Hommey
Cosmin Sabou
Csoregi Natalia
Jed Davis
André Bargull
Makoto Kato
Paul Bone
Paul Zuehlcke
Gabriele Svelto
Niklas Goegge
Aaron Klotz
Doug Thayer
Marian-Vasile Laza
Jeff Gilbert
Randell Jesup
Kashav Madan
Bob Owen
Florian Quèze