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
dom/media/ipc/RDDProcessManager.cpp(320,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
gpuProcessPid != -1 ? gpuProcessPid : base::GetCurrentProcId();
~~~~~~~~~~~~~ ^ ~~
dom/media/ipc/RDDProcessManager.cpp(332,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (gpuProcessPid != -1) {
~~~~~~~~~~~~~ ^ ~~
gfx/layers/ipc/SharedSurfacesParent.cpp(360,38): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (!gpm || gpm->GPUProcessPid() != -1) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~
ipc/glue/MessageChannel.cpp(2145,13): error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const base::ProcessId' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (pid != base::kInvalidProcessId &&
~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144688
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
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
This is no longer necessary as the Quantum DOM project is no longer
happening, and removing support simplifies various components inside of
IPDL.
As some code used the support to get a `nsISerialEventTarget` for an
actor's worker thread, that method was replaced with a method which
instead pulls the nsISerialEventTarget from the MessageChannel and
should work on all actors.
Differential Revision: https://phabricator.services.mozilla.com/D135411
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
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
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 removes the last form of unique link between two MessageChannels so that
all MessageChannels communicate using PortLink, as it is fairly straightforward
to use PortLink to communicate between two threads in-process.
Differential Revision: https://phabricator.services.mozilla.com/D116672
