Handle crash with the old way if the fork server is prefed out, and waitpid() for all available stat changes of children processes in the forkserver.
Differential Revision: https://phabricator.services.mozilla.com/D110507
Handle crash with the old way if the fork server is prefed out, and waitpid() for all available stat changes of children processes in the forkserver.
Differential Revision: https://phabricator.services.mozilla.com/D110507
ipc/chromium/src/chrome/common/ipc_channel_win.cc(133,8): error: variable 'waited' set but not used [-Werror,-Wunused-but-set-variable]
bool waited = false;
^
ipc/mscom/InterceptorLog.cpp(183,12): error: variable 'rv' set but not used [-Werror,-Wunused-but-set-variable]
nsresult rv = mThread->Dispatch(
^
Differential Revision: https://phabricator.services.mozilla.com/D126455
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
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
mozilla-central has some imported files of build_config.h from Chromium.
Actually although they doesn't have riscv64 defines yet, I would like to
add it to build Firefox for riscv64.
Differential Revision: https://phabricator.services.mozilla.com/D119051
These port attachments are stored directly on the IPC::Message until the
message is ready to be routed to another process, at which point they will be
attached to the port in WillBeRoutedExternally. When the message is then
received on the other side, the ports will be re-extracted from the
UserMessageEvent before it is discarded and re-added to the IPC::Message so
that serializers only need to interact directly with the IPC::Message type.
Differential Revision: https://phabricator.services.mozilla.com/D116669
This is used because, unlike in Mojo, we cannot get from the IPC::Message
object to its enclosing UserMessageEvent object to attach more ports to it, and
this extra parameter makes that easy to do.
Differential Revision: https://phabricator.services.mozilla.com/D116668
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
The NodeController and NodeChannel types act as the backbone connecting the
existing IPC logic and driving the ports routing code. Individual NodeChannel
objects wrap and respond to messages from IPC::Channel, and the NodeController
orchestrates all messaging for a process.
The design of these types are inspired by the types with the same names from
Mojo but have been simplified and streamlined to only support features used by
Gecko.
Support for attaching ports or handles to messages hasn't been added yet, but
can be added in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D112775
These will be used to serialize extra event metadata into IPC messages when
they're sent over the ports infrastructure. In the future better integration
may be used to reduce the overhead of this if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D112773
The ports library import came with 2 gtests. This patch gets them running under
our gtest runner to ensure we don't break the ports functionality.
Differential Revision: https://phabricator.services.mozilla.com/D112768
These port attachments are stored directly on the IPC::Message until the
message is ready to be routed to another process, at which point they will be
attached to the port in WillBeRoutedExternally. When the message is then
received on the other side, the ports will be re-extracted from the
UserMessageEvent before it is discarded and re-added to the IPC::Message so
that serializers only need to interact directly with the IPC::Message type.
Differential Revision: https://phabricator.services.mozilla.com/D116669
This is used because, unlike in Mojo, we cannot get from the IPC::Message
object to its enclosing UserMessageEvent object to attach more ports to it, and
this extra parameter makes that easy to do.
Differential Revision: https://phabricator.services.mozilla.com/D116668
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
This also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
The NodeController and NodeChannel types act as the backbone connecting the
existing IPC logic and driving the ports routing code. Individual NodeChannel
objects wrap and respond to messages from IPC::Channel, and the NodeController
orchestrates all messaging for a process.
The design of these types are inspired by the types with the same names from
Mojo but have been simplified and streamlined to only support features used by
Gecko.
Support for attaching ports or handles to messages hasn't been added yet, but
can be added in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D112775
These will be used to serialize extra event metadata into IPC messages when
they're sent over the ports infrastructure. In the future better integration
may be used to reduce the overhead of this if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D112773
The ports library import came with 2 gtests. This patch gets them running under
our gtest runner to ensure we don't break the ports functionality.
Differential Revision: https://phabricator.services.mozilla.com/D112768
Thinker Li
Noemi Erli
Petr Sumbera
Mike Hommey
Bob Owen
Marian-Vasile Laza
Andi-Bogdan Postelnicu
Jed Davis
Tom Ritter
Makoto Kato
Nika Layzell
Butkovits Atila
Florian Quèze
Iulian Moraru
Rob Lemley
Olli Pettay