This requires a small change to the filesystem code, as the
FileSystemManager::BeginRequest signature explicitly uses the type
outside of IPC code.
We never need to copy the request object, so using std::function applies
unnecessary restrictions.
Differential Revision: https://phabricator.services.mozilla.com/D228098
This reduces the amount of casting required during async replies checks,
and ensures that the lifetimes of async replies callbacks are directly
tied to IPDL actor lifetimes.
This change does lose the unresolved-ipc-responses nsIMemoryReporter
implementation, as they are no longer stored as centrally.
Differential Revision: https://phabricator.services.mozilla.com/D226061
This method (intended to be used only in tests) returns whether the current transaction stack is
complete, and is used by TestHangs to determine when to continue in the HangButReceive subtest.
Differential Revision: https://phabricator.services.mozilla.com/D203964
This method (intended to be used only in tests) blocks until the current transaction stack is
complete, and is used by TestHangs to determine when to continue in the HangButReceive subtest.
Differential Revision: https://phabricator.services.mozilla.com/D203964
Text passed to `IPCResult::Fail` (and, therefore, text passed to
`IPC_FAIL`) may end up in telemetry.
To avoid accidentally capturing unwanted information, restrict all such
text to compile-time constant strings, unless approved by data-review.
Differential Revision: https://phabricator.services.mozilla.com/D180152
This should avoid potential fuzzing-only issues which would be caused by
the actor being torn down synchronously after a FatalError or KillHard.
Instead, the state is set to error synchronously, blocking all further
message sending/receiving, and the notification is made async, similar
to how it is handled for normal channel errors.
Differential Revision: https://phabricator.services.mozilla.com/D180254
This refactoring cleans up some dead code, and makes some semantic
changes to how the MessageChannel lifecycle is handled.
These changes ensure that messages which were sent by a peer before the
GOODBYE message will be delivered, without allowing messages sent after
the GOODBYE message (e.g. by a misbehaving process) to be delivered.
The lifecycle and shutdown states were simplified, and moved to be
entirely in MessageChannel, rather than split between MessageChannel and
MessageLink.
The dead-code ChannelTimeout error state was removed, along with the
corresponding CloseWithTimeout method.
The CloseWithError method was updated to behave more consistently with
the normal Close method, synchronously triggering a connection error,
and closing the MessageLink. This method is currently unused, but will
useful in the future for handling processing errors.
Differential Revision: https://phabricator.services.mozilla.com/D178382
This actually hasn't ever been used in a shipping build of Firefox.
Although sync IPDL was tried with Windos a11y for a while when e10s was still disabled, it was never feasible and was replaced with COM proxying.
Differential Revision: https://phabricator.services.mozilla.com/D177965
This was only ever used by the old accessibility architecture based on content process COM proxies, which is now being removed.
Differential Revision: https://phabricator.services.mozilla.com/D177964
This actually hasn't ever been used in a shipping build of Firefox.
Although sync IPDL was tried with Windos a11y for a while when e10s was still disabled, it was never feasible and was replaced with COM proxying.
Differential Revision: https://phabricator.services.mozilla.com/D177965
This was only ever used by the old accessibility architecture based on content process COM proxies, which is now being removed.
Differential Revision: https://phabricator.services.mozilla.com/D177964
This refactoring cleans up some dead code, and makes some semantic
changes to how the MessageChannel lifecycle is handled.
These changes ensure that messages which were sent by a peer before the
GOODBYE message will be delivered, without allowing messages sent after
the GOODBYE message (e.g. by a misbehaving process) to be delivered.
The lifecycle and shutdown states were simplified, and moved to be
entirely in MessageChannel, rather than split between MessageChannel and
MessageLink.
The dead-code ChannelTimeout error state was removed, along with the
corresponding CloseWithTimeout method.
The CloseWithError method was updated to behave more consistently with
the normal Close method, synchronously triggering a connection error,
and closing the MessageLink. This method is currently unused, but will
useful in the future for handling processing errors.
Differential Revision: https://phabricator.services.mozilla.com/D178382
This is intended to be used to mark messages which do nothing on the
receiving side other than setting up state for future IPC messages,
meaning that the send can be delayed until other more important work is
complete, or until a non-LazySend IPC message is sent.
This does not break any message ordering guarantees, as the lazy
messages will be sent in order before any non-lazy messages are sent.
Differential Revision: https://phabricator.services.mozilla.com/D164274
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
All accesses except those through the xpcom interfaces were already
guarded, and given it can be mutated, this seemed easier than adding
thread assertions or similar.
Differential Revision: https://phabricator.services.mozilla.com/D145886
This makes passing around the type more consistent, and hopefully will make
changes to IPC::Message easier to work with in the future.
In addition, this should save us a few copies as we move the message type into
and out of UniquePtr, however I expect this won't make much of a difference.
Differential Revision: https://phabricator.services.mozilla.com/D145885
All accesses except those through the xpcom interfaces were already
guarded, and given it can be mutated, this seemed easier than adding
thread assertions or similar.
Differential Revision: https://phabricator.services.mozilla.com/D145886
This makes passing around the type more consistent, and hopefully will make
changes to IPC::Message easier to work with in the future.
In addition, this should save us a few copies as we move the message type into
and out of UniquePtr, however I expect this won't make much of a difference.
Differential Revision: https://phabricator.services.mozilla.com/D145885
Like DataPipe, the Monitor in this case is shared between multiple objects and
needs some helper methods.
Theoretically REQUIRES annotations should be added to methods on the
transaction type, however the requirement would be difficult to express,
leading to a lot of assertion methods cluttering up the code, so it was left
out for now.
Differential Revision: https://phabricator.services.mozilla.com/D141534
Like DataPipe, the Monitor in this case is shared between multiple objects and
needs some helper methods.
Theoretically REQUIRES annotations should be added to methods on the
transaction type, however the requirement would be difficult to express,
leading to a lot of assertion methods cluttering up the code, so it was left
out for now.
Differential Revision: https://phabricator.services.mozilla.com/D141534
Releasing ActorLifecycleProxy can lead to the IToplevelProtocol being
destroyed, due to the reference being the last reference. If this happens, we
can deadlock due to the MessageChannel embedded in IToplevelProtocol locking
mMonitor during its' destructor. This patch moves acquiring the proxy earlier
in the method, so that we do not deadlock in this case any longer.
Differential Revision: https://phabricator.services.mozilla.com/D137169
This simplifies the logic around descriptors significantly, which is
especially useful considering how few places use the type. There is a
small change required on Windows to create the NamedPipe directly and
transfer around each end's handle, rather than connecting between
processes after the fact.
A named pipe has to be used, rather than an anonymous pipe, as
bidirectional communication is required.
Differential Revision: https://phabricator.services.mozilla.com/D130381
This simplifies the logic around descriptors significantly, which is
especially useful considering how few places use the type. There is a
small change required on Windows to create the NamedPipe directly and
transfer around each end's handle, rather than connecting between
processes after the fact.
A named pipe has to be used, rather than an anonymous pipe, as
bidirectional communication is required.
Differential Revision: https://phabricator.services.mozilla.com/D130381
All uses of the intr message type have been removed from the tree, and the only
remaining uses are in IPDL tests, which currently do not test the IPDL runtime.
This test fully removes support for intr messages from the MessageChannel
interface.
Differential Revision: https://phabricator.services.mozilla.com/D136500
