Consider PlatformThread::Join() to be blocking IO.

chrome/browser/browser_process_impl.cc

Index: chrome/browser/browser_process_impl.cc
diff --git a/chrome/browser/browser_process_impl.cc b/chrome/browser/browser_process_impl.cc
index e2601849a7792c07b92499cda5717a2a81b4b9e2..1bcb9e72a0923e186880f3f0bc99ef68fd48a594 100644
--- a/chrome/browser/browser_process_impl.cc
+++ b/chrome/browser/browser_process_impl.cc
@@ -13,6 +13,7 @@
 #include "base/path_service.h"
 #include "base/task.h"
 #include "base/thread.h"
+#include "base/thread_restrictions.h"
 #include "base/waitable_event.h"
 #include "chrome/browser/appcache/chrome_appcache_service.h"
 #include "chrome/browser/automation/automation_provider_list.h"
@@ -250,6 +251,12 @@ unsigned int BrowserProcessImpl::ReleaseModule() {
   DCHECK_NE(0u, module_ref_count_);
   module_ref_count_--;
   if (0 == module_ref_count_) {
+    // Allow UI and IO threads to do blocking IO on shutdown, since we do a lot
+    // of it on shutdown for valid reasons.

[Evan Martin, 2010/12/10 21:43:04]

Heh, I hope this is the right place for this code...

[willchan no longer on Chromium, 2010/12/10 21:54:28]

What, you don't trust me? :)  Try it for yourself if you'd like.  But yeah, from
my extensive experience trawling through the morass of shutdown code nonsense,
this is the right place to do it.  It's interesting to note that APP_TERMINATING
is not the right signal to watch, because the automation provider can trigger
shutdown in ways that bypass APP_TERMINATING.  But this is the way we stop the
UI thread, so it's guaranteed to always work.

+    base::ThreadRestrictions::SetIOAllowed(true);
+    io_thread()->message_loop()->PostTask(
+        FROM_HERE,
+        NewRunnableFunction(&base::ThreadRestrictions::SetIOAllowed, true));
     MessageLoop::current()->PostTask(
         FROM_HERE, NewRunnableFunction(DidEndMainMessageLoop));
     MessageLoop::current()->Quit();