Delete method MessageQueue::set_socketserver

webrtc/base/thread.cc

Index: webrtc/base/thread.cc
diff --git a/webrtc/base/thread.cc b/webrtc/base/thread.cc
index 9a71c1aa3fd352130677641d54b2ff8a79ce5d96..1be5196c7dffbf8325b679c1504f19df1eb7f2b3 100644
--- a/webrtc/base/thread.cc
+++ b/webrtc/base/thread.cc
@@ -528,4 +528,26 @@ AutoThread::~AutoThread() {
   }
 }
 
+AutoSocketServerThread::AutoSocketServerThread(SocketServer* ss)
+    : Thread(ss) {
+  old_thread_ = ThreadManager::Instance()->CurrentThread();
+  rtc::ThreadManager::Instance()->SetCurrentThread(this);
+  if (old_thread_) {
+    MessageQueueManager::Remove(old_thread_);
+  }
+}
+
+AutoSocketServerThread::~AutoSocketServerThread() {
+  RTC_DCHECK(ThreadManager::Instance()->CurrentThread() == this);
+  // Some tests post destroy messages to this thread. To avoid memory
+  // leaks, we have to process those messages. In particular
+  // P2PTransportChannelPingTest, relying on the message posted in
+  // cricket::Connection::Destroy.

[Taylor Brandstetter, 2017/05/03 22:17:27]

I'd consider this a bug with cricket::Connection::Destroy. It could happen if an
application closes a PeerConnection and then quickly destroys the
PeerConnectionFactory (along with the networking thread on which the message was
posted). If you agree, can you leave a TODO to fix the cricket::Connection
memory leak in a more general way?

[nisse-webrtc, 2017/05/05 07:58:35]

Done.

+  ProcessMessages(0);
+  rtc::ThreadManager::Instance()->SetCurrentThread(old_thread_);
+  if (old_thread_) {
+    MessageQueueManager::Add(old_thread_);
+  }
+}
+
 }  // namespace rtc