Relax check for message loop in SequencedWorkerPool

base/threading/sequenced_worker_pool.h

Index: base/threading/sequenced_worker_pool.h
diff --git a/base/threading/sequenced_worker_pool.h b/base/threading/sequenced_worker_pool.h
index ded2b0a5e730ed491bde3e7341357af4968da28a..83d677a81a565476bc525567f51ca6892660c6a9 100644
--- a/base/threading/sequenced_worker_pool.h
+++ b/base/threading/sequenced_worker_pool.h
@@ -127,8 +127,12 @@ class BASE_EXPORT SequencedWorkerPool : public TaskRunner {
     virtual void OnDestruct() = 0;
   };
 
+  // When constructing a SequencedWorkerPool, there must be a
+  // MessageLoop on the current thread unless you plan to deliberately
+  // leak it.

[joth, 2012/03/16 12:04:04]

FWIW reading this another approach occurred to me: we could make it explicit in
the API when an instance is intended to be leaked by requiring an extra
SequencedWorkerPool::LEAKY enum param to be passed, the absence of which would
invoke the current DCHECK for message loop (or even, allow the user to pass in
the desired destruct message loop).

Then in OnDestroy if the destruction_message_loop_ is NULL it can just bail out
(i.e. implementing the 'leak' semantics, even if the caller releases all
ref-counts onto the pool). (Optionally it could go into a half-dead state, where
it would DCHECK if any new tasks were posted).

+
   // Pass the maximum number of threads (they will be lazily created as needed)
-  // and a prefix for the thread name to ad in debugging.
+  // and a prefix for the thread name to aid in debugging.
   SequencedWorkerPool(size_t max_threads,
                       const std::string& thread_name_prefix);