Delete SignalThread class.

webrtc/base/messagequeue.h

Index: webrtc/base/messagequeue.h
diff --git a/webrtc/base/messagequeue.h b/webrtc/base/messagequeue.h
index e39c9f9869a4b19ee16c225cdd20bfee7121c412..8981d799783aaf166174845a5657110b6774a540 100644
--- a/webrtc/base/messagequeue.h
+++ b/webrtc/base/messagequeue.h
@@ -147,6 +147,21 @@ class DisposeData : public MessageData {
   T* data_;
 };
 
+class CallableData : public MessageData {
+ public:
+  virtual void Call(void) = 0;

[tommi, 2017/06/27 12:01:14]

virtual void Call() = 0;

Btw, this seems to now basically seem to be the same as QueuedTask(), so would
it make sense to encourage use of TaskQueue instead (in a comment)?  Possibly
even call the method Run()?  hmm...or maybe that would just make things
confusing.

Another thing to consider is if we should just have an approach like this
instead :)

class QueuedTaskAdapter : public MessageData {
 public:
  < ctor + dtor + additional fluff>
  std::unique_ptr<QueuedTask> task_;
};

One benefit of that would be that instead of adding one more interface to
MessageData et al, we introduce an explicit adapter between TaskQueue and
libjingle queues, that encourage use of the TaskQueue type.

[kwiberg-webrtc, 2017/06/27 13:14:56]

sgtm---the new Post() call could take a unique_ptr<QueuedTask> argument instead
of a FunctorT, and everything else could be hidden in the implementation. I like
QueuedTask, except for the thing with the return value from Run() that says
whether the queue should delete the QueuedTask or relinquish ownership.

[nisse-webrtc, 2017/06/28 11:47:54]

Done.
 
I've thought about adding a method

MessageQueue::PostTask(std::unique_ptr<QueuedTask> task);

to make it possible to use an rtc::Thread more or less the same way as a task
queue. Which seems to be pretty close to what you are suggesting. Would that
make sense?

And renaming Call() --> Run() would improve consistency, I think. Do we need to
rename the CallableData interface too, and how?

[tommi, 2017/06/28 13:17:33]

yes, I think so
Do we need CallableData as an interface in that case?  I'm wondering if we could
get away with a custom implementation of MessageData that owns a QueuedTask and
our handler recognizes.  The custom type wouldn't implement a new interface but
basically just be a vehicle for carrying the QueuedTask object.  The handler
then takes care of the logic.

[nisse-webrtc, 2017/06/29 10:40:31]

I've renamed Call to Run, and Callable to Runnable.

[nisse-webrtc, 2017/06/29 10:40:32]

Sounds like it could work, I'll give it a try, but might not get ready before I
leave for vacation. I guess there's no hurry, but if you think the current
version of the cl is good enough, we could land it now, and get back to
QueuedTask later.

+};
+
+template <class FunctorT>
+class FunctorData : public CallableData {
+ public:
+  explicit FunctorData(FunctorT functor) : functor_(std::move(functor)) {}
+  void Call(void) override { functor_(); }

[tommi, 2017/06/27 12:01:14]

same here (no 'void' when there aren't any arguments)

+
+ private:
+  FunctorT functor_;
+};
+
 const uint32_t MQID_ANY = static_cast<uint32_t>(-1);
 const uint32_t MQID_DISPOSE = static_cast<uint32_t>(-2);
 
@@ -236,6 +251,17 @@ class MessageQueue {
                     uint32_t id = 0,
                     MessageData* pdata = nullptr,
                     bool time_sensitive = false);
+
+  // Additional type check, or else it collides with calls to the
+  // above Post method with the optional arguments omitted.
+  template <class FunctorT,
+            typename std::enable_if<!std::is_pointer<FunctorT>::value>::type* =
+                nullptr>
+  void Post(const Location& posted_from, FunctorT functor) {
+    PostFunctorInternal(posted_from,
+                        new FunctorData<FunctorT>(std::move(functor)));
+  }
+
   virtual void PostDelayed(const Location& posted_from,
                            int cmsDelay,
                            MessageHandler* phandler,
@@ -312,6 +338,9 @@ class MessageQueue {
   bool fDestroyed_;
 
  private:
+  void PostFunctorInternal(const Location& posted_from,
+                           CallableData* message_data);
+
   volatile int stop_;
 
   // The SocketServer might not be owned by MessageQueue.