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

net/socket/ssl_client_socket_openssl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // OpenSSL binding for SSLClientSocket. The class layout and general principle
 // of operation is derived from SSLClientSocketNSS.
 
 #include "net/socket/ssl_client_socket_openssl.h"
 
 #include <openssl/err.h>
@@ skipping 375 matching lines @@
     const base::Closure& callback) {
   error_callback_ = callback;
 }
 
 void SSLClientSocketOpenSSL::SetIsLeader() {
   is_leader_ = true;
 }
 
 void SSLClientSocketOpenSSL::OnSocketFailure() {
   if (is_leader_)
-    error_callback_.Run();
+    base::MessageLoopForIO::current()->PostTask(FROM_HERE, error_callback_);

[wtc, 2014/07/08 17:37:03]

IMPORTANT: please verify that this task should still be run if this object is
deleted.

[mshelley, 2014/07/09 21:53:06]

By "this object" do you mean the SSLClientSocketOpenSSL that this method is
called on, or the SSLConnectJobMessenger that is bound to the callback? 

If you're referring to the socket, then yes the task should still be run even if
the socket is deleted. The callback is runng OnJobFailed, which doesn't actually
use the socket of the failed job. It just removes this socket from
connecting_sockets_, and then tells the next socket in
pending_sockets_and_callbacks_ to connect. 

If you're referring to the SSLConnectJobMessenger, as of now that won't be
deleted until the SSLConnectJobFactory is deleted. My understanding was that the
SSLConnectJobFactory should outlive all sockets because it's owned by socket
pool, so I don't think that the messenger being deleted should ever be a
problem?

Note that I do plan to change the handling of SSLConnectJobMessengers so that
they are deleted after all of their pending sockets have been told to connect.  

[Ryan Sleevi, 2014/07/09 22:40:37]

To be clear: The situation concerned is

Precondition:
Contents of MessageLoop
  Task1 - Run something that will eventually call OnSocketFailure
  Task2 - Shut things down

At T0, you run Task1, which schedules a new Task, Task3, to run error_callback_
At T1, Task2 runs, deleting everything
At T2, error_callback_ is now run, except the thing that created the
ErrorCallback may have gone away.

Wan-Teh's fundamental question was that if, as part of T1/Task2, this object is
deleted, is it still correct to call error_callback_?

The current design of the net/socket interfaces is that once an object is
destroyed, *no* callbacks for pending operations will be called. Which means
calling T2/error_callback_ would be a violation of that principle, because the
associated socket will have gone away.

 }
 
 void SSLClientSocketOpenSSL::GetSSLCertRequestInfo(
     SSLCertRequestInfo* cert_request_info) {
   cert_request_info->host_and_port = host_and_port_;
   cert_request_info->cert_authorities = cert_authorities_;
   cert_request_info->cert_key_types = cert_key_types_;
 }
 
 SSLClientSocket::NextProtoStatus SSLClientSocketOpenSSL::GetNextProto(
@@ skipping 1057 matching lines @@
   DVLOG(2) << "next protocol: '" << npn_proto_ << "' status: " << npn_status_;
   return SSL_TLSEXT_ERR_OK;
 }
 
 scoped_refptr<X509Certificate>
 SSLClientSocketOpenSSL::GetUnverifiedServerCertificateChain() const {
   return server_cert_;
 }
 
 }  // namespace net