Makes waiting SSLConnectJobs use the message loops to resume their connection.

net/socket/ssl_client_socket_pool.cc

Index: net/socket/ssl_client_socket_pool.cc
diff --git a/net/socket/ssl_client_socket_pool.cc b/net/socket/ssl_client_socket_pool.cc
index d3fe8f536c1834e9566a15d96b98f1afeb9cec47..5a0f973f0abe506f7f9755255e40c80fc7578742 100644
--- a/net/socket/ssl_client_socket_pool.cc
+++ b/net/socket/ssl_client_socket_pool.cc
@@ -10,6 +10,7 @@
 #include "base/metrics/histogram.h"
 #include "base/metrics/sparse_histogram.h"
 #include "base/stl_util.h"
+#include "base/thread_task_runner_handle.h"
 #include "base/values.h"
 #include "net/base/host_port_pair.h"
 #include "net/base/net_errors.h"
@@ -109,6 +110,9 @@ void SSLConnectJobMessenger::RemovePendingSocket(SSLClientSocket* ssl_socket) {
   }
 }
 
+SSLConnectJobMessenger::SSLConnectJobMessenger() : weak_factory_(this) {
+}
+
 bool SSLConnectJobMessenger::CanProceed(SSLClientSocket* ssl_socket) {
   // If the session is in the session cache, or there are no connecting
   // sockets, allow the connection to proceed.
@@ -118,9 +122,8 @@ bool SSLConnectJobMessenger::CanProceed(SSLClientSocket* ssl_socket) {
 void SSLConnectJobMessenger::MonitorConnectionResult(
     SSLClientSocket* ssl_socket) {
   connecting_sockets_.push_back(ssl_socket);
-  // TODO(mshelley): Both of these callbacks will use WeakPtr in future CL.
   ssl_socket->SetHandshakeCompletionCallback(base::Bind(
-      &SSLConnectJobMessenger::OnJobCompleted, base::Unretained(this)));
+      &SSLConnectJobMessenger::OnJobCompleted, weak_factory_.GetWeakPtr()));
 }
 
 void SSLConnectJobMessenger::AddPendingSocket(SSLClientSocket* ssl_socket,
@@ -139,11 +142,13 @@ void SSLConnectJobMessenger::OnJobCompleted() {
 
 void SSLConnectJobMessenger::RunAllCallbacks(
     const SSLPendingSocketsAndCallbacks& pending_sockets_and_callbacks) {
+  scoped_refptr<base::SingleThreadTaskRunner> task_runner =
+      base::ThreadTaskRunnerHandle::Get();
   for (std::vector<SocketAndCallback>::const_iterator it =
            pending_sockets_and_callbacks.begin();
        it != pending_sockets_and_callbacks.end();
        ++it) {
-    it->callback.Run();
+    task_runner->PostTask(FROM_HERE, it->callback);

[wtc, 2014/08/05 00:44:57]

1. I think running the callbacks directly is safe and improves performance. But
I won't block this change.

We don't call SetHandshakeCompletionCallback on any of these pending sockets, so
the callbacks won't call the SSLConnectJobMessenger. Therefore, the "somewhat
recursive call sequence" you mentioned in the CL's description should not occur.

2. Please add a comment to explain why it is necessary or useful to post tasks
to run the callbacks later.

[Ryan Sleevi, 2014/08/06 02:15:50]

I don't think this is entirely true. Any one of these callbacks could create a
new SSLSocket, which would potentially fall back into this messenger. Any number
of side-effects could occur.

Now, whether or not they do in this CL is irrelevant, I think - it's more about
making sure the API contract is consistent.

   }
 }