ThreadRestrictions: disallow blocking IO on the UI thread

base/nss_util.cc

Index: base/nss_util.cc
diff --git a/base/nss_util.cc b/base/nss_util.cc
index 5c7cafd5a36561ab558000287bfdf2d32de6352d..95b00826bfa0cbc0415def09aefa6bc41fe38fbe 100644
--- a/base/nss_util.cc
+++ b/base/nss_util.cc
@@ -22,6 +22,7 @@
 #include "base/logging.h"
 #include "base/singleton.h"
 #include "base/stringprintf.h"
+#include "base/thread_restrictions.h"
 
 // USE_NSS means we use NSS for everything crypto-related.  If USE_NSS is not
 // defined, such as on Mac and Windows, we use NSS for SSL only -- we don't
@@ -310,6 +311,10 @@ void EnsureNSPRInit() {
 }
 
 void EnsureNSSInit() {
+  // Initializing SSL causes us to do blocking IO.
+  // Temporarily allow it until we fix
+  //   http://code.google.com/p/chromium/issues/detail?id=59847

[willchan no longer on Chromium, 2010/10/27 00:06:18]

The referenced bug is for this happening on the IO thread, which disagrees with
your changelist description.  if this happens on the IO thread, then that's
fine, it's a known bug and it'll be hard to work around.  If it's the UI thread,
then I'm a bit more disturbed.  Can you clarify?

A more anal approach would be to add the ScopedAllowIO higher up so we aren't
allowed to call EnsureNSSInit() on both the UI and IO thread, just whatever code
is calling this from the IO thread.

+  base::ThreadRestrictions::ScopedAllowIO allow_io;
   Singleton<NSSInitSingleton>::get();
 }