Add an explicit function to init NSS for SSL server sockets

remoting/client/plugin/chromoting_instance.cc

Index: remoting/client/plugin/chromoting_instance.cc
diff --git a/remoting/client/plugin/chromoting_instance.cc b/remoting/client/plugin/chromoting_instance.cc
index 8435e1e59517df04d18d0aa810815cc410ab8c4b..6a7cf82fcf4663d82b2c4a61689aabefd79246f5 100644
--- a/remoting/client/plugin/chromoting_instance.cc
+++ b/remoting/client/plugin/chromoting_instance.cc
@@ -21,6 +21,7 @@
 #include "base/values.h"
 #include "jingle/glue/thread_wrapper.h"
 #include "media/base/media.h"
+#include "net/socket/ssl_server_socket.h"
 #include "ppapi/cpp/completion_callback.h"
 #include "ppapi/cpp/input_event.h"
 #include "ppapi/cpp/mouse_cursor.h"
@@ -187,6 +188,8 @@ bool ChromotingInstance::Init(uint32_t argc,
     return false;
   }
 
+  net::EnableSSLServerSockets();

[Wez, 2012/06/12 21:30:35]

In practice I doubt it's an issue, but the Chromoting PPAPI plugin currently
runs in the renderer, which may contain other threads that could trigger an
action on an SSL server socket.

[Wez, 2012/06/12 21:30:35]

nit: Add a comment to explain why we need to have the call at this point.

[Ryan Sleevi, 2012/06/12 22:35:40]

Right. I was trying to find where the post-sandbox Renderer init code lives. The
Pre-sandbox code configures NSS (for all renderer types), so it would make sense
that the post-sandbox code would initialize the server sockets.

If it is an issue though, we'll hit the DCHECK right away.

+
   // Start all the threads.
   context_.Start();