Wait for URLBlacklist update tasks on automation tests.

content/browser/browser_thread.h

 // Copyright (c) 2011 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.
 
 #ifndef CONTENT_BROWSER_BROWSER_THREAD_H_
 #define CONTENT_BROWSER_BROWSER_THREAD_H_
 #pragma once
 
 #include "base/callback.h"
 #include "base/synchronization/lock.h"
@@ skipping 150 matching lines @@
 
   // Callable on any thread.  Returns whether the threads message loop is valid.
   // If this returns false it means the thread is in the process of shutting
   // down.
   static bool IsMessageLoopValid(ID identifier);
 
   // If the current message loop is one of the known threads, returns true and
   // sets identifier to its ID.  Otherwise returns false.
   static bool GetCurrentThreadIdentifier(ID* identifier);
 
+  // Runs all the current pending tasks on the given thread's message loop.
+  // This call blocks until those tasks are executed, effectively making the
+  // current thread block on |identifier|. Avoid using this.
+  // Returns false if |identifier| is the current thread, or a task couldn't be
+  // posted to |identifier|'s message loop.
+  static bool WaitForPendingTasksOn(ID identifier);

[jam, 2011/10/14 17:19:30]

this is most certainly a function that we don't want on BrowserThread. any such
function, once it's in, would be misused.

check out http://dev.chromium.org/developers/design-documents/threading

"Chromium is a very multithreaded product. We try to keep the UI as responsive
as possible, and this means not blocking the UI thread with any blocking I/O or
other expensive operations. Our approach is to use message passing as the way of
communicating between threads. We discourage locking and threadsafe objects.
Instead, objects live on only one thread, we pass messages between threads for
communication, and we use callback interfaces (implemented by message passing)
for most cross-thread requests."


I don't know the details of the test that you're trying to fix, but it seems
that you can do this waiting in the test code yourself, without touching the
content code.

+
   // Callers can hold on to a refcounted MessageLoopProxy beyond the lifetime
   // of the thread.
   static scoped_refptr<base::MessageLoopProxy> GetMessageLoopProxyForThread(
       ID identifier);
 
   // Use these templates in conjuction with RefCountedThreadSafe when you want
   // to ensure that an object is deleted on a specific thread.  This is needed
   // when an object can hop between threads (i.e. IO -> FILE -> IO), and thread
   // switching delays can mean that the final IO tasks executes before the FILE
   // task's stack unwinds.  This would lead to the object destructing on the
@@ skipping 61 matching lines @@
   static base::Lock lock_;
 
   // An array of the BrowserThread objects.  This array is protected by |lock_|.
   // The threads are not owned by this array.  Typically, the threads are owned
   // on the UI thread by the g_browser_process object.  BrowserThreads remove
   // themselves from this array upon destruction.
   static BrowserThread* browser_threads_[ID_COUNT];
 };
 
 #endif  // CONTENT_BROWSER_BROWSER_THREAD_H_