Bug 1397468 - Shmem creation/destruction messages should not be SystemGroup (r=dvander)
authorBill McCloskey <billm@mozilla.com>
Fri, 01 Sep 2017 16:29:25 -0700
changeset 429136 2f0ecd56c80455a10b4d41d249cd7abcd1eb92b2
parent 429135 25413c572c6e618128d37f898da5261c4f9b5d3c
child 429137 8eaa67e815a5283834c43fbd0220590e4c14859a
push id7761
push userjlund@mozilla.com
push dateFri, 15 Sep 2017 00:19:52 +0000
treeherdermozilla-beta@c38455951db4 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersdvander
bugs1397468
milestone57.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1397468 - Shmem creation/destruction messages should not be SystemGroup (r=dvander) It's important that shmem creation/destruction messages be ordered correctly with respect to other messages that use shmems. For example, if we create a shmem with ID 10 and then send a message that references shmem 10, then the creation message must be handled before the referencing message. If shmem creation/destruction messages go in a separate queue from other messages, this ordering may not be preserved. Leaving shmem creation/destruction unlabeled will give us the correct ordering. Eventually, though, we'll need to provide a solution that doesn't bottleneck the event queue. MozReview-Commit-ID: 88MrslRrfnh
ipc/glue/ProtocolUtils.cpp
--- a/ipc/glue/ProtocolUtils.cpp
+++ b/ipc/glue/ProtocolUtils.cpp
@@ -821,23 +821,16 @@ IToplevelProtocol::ShmemDestroyed(const 
     Shmem::Dealloc(Shmem::IHadBetterBeIPDLCodeCallingThis_OtherwiseIAmADoodyhead(), rawmem);
   }
   return true;
 }
 
 already_AddRefed<nsIEventTarget>
 IToplevelProtocol::GetMessageEventTarget(const Message& aMsg)
 {
-  if (IsMainThreadProtocol() && SystemGroup::Initialized()) {
-    if (aMsg.type() == SHMEM_CREATED_MESSAGE_TYPE ||
-        aMsg.type() == SHMEM_DESTROYED_MESSAGE_TYPE) {
-      return do_AddRef(SystemGroup::EventTargetFor(TaskCategory::Other));
-    }
-  }
-
   int32_t route = aMsg.routing_id();
 
   Maybe<MutexAutoLock> lock;
   lock.emplace(mEventTargetMutex);
 
   nsCOMPtr<nsIEventTarget> target = mEventTargetMap.Lookup(route);
 
   if (aMsg.is_constructor()) {