Create base::WorkerPoolJob. Use it for HostResolverImpl and DirectoryLister.

base/worker_pool_job_unittest.cc

Index: base/worker_pool_job_unittest.cc
diff --git a/base/worker_pool_job_unittest.cc b/base/worker_pool_job_unittest.cc
new file mode 100644
index 0000000000000000000000000000000000000000..aa306a3929645630fe7f51dbcbc219801c73e211
--- /dev/null
+++ b/base/worker_pool_job_unittest.cc
@@ -0,0 +1,122 @@
+// Copyright (c) 2010 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.
+
+#include "base/worker_pool_job.h"
+
+#include "base/callback.h"
+#include "base/message_loop.h"
+#include "base/waitable_event.h"
+#include "testing/gtest/include/gtest/gtest.h"
+
+namespace base {
+
+namespace {
+
+class TestCallback : public CallbackRunner<Tuple0> {

[eroman, 2010/12/22 23:25:08]

Can you just fold this logic into TestJob by having a "WaitUntilCompleted()"
method?

[willchan no longer on Chromium, 2010/12/24 00:47:34]

Done.

+ public:
+  TestCallback()
+      : have_run_(false),
+        waiting_for_run_(false) {
+  }
+
+  void Wait() {
+    DCHECK(!waiting_for_run_);
+    while (!have_run_) {
+      waiting_for_run_ = true;
+      MessageLoop::current()->Run();
+      waiting_for_run_ = false;
+    }
+    have_run_ = false;  // auto-reset for next callback
+  }
+
+  virtual void RunWithParams(const Tuple0& params) {
+    if (waiting_for_run_)
+      MessageLoop::current()->Quit();
+    have_run_ = true;
+  }
+
+ private:
+  bool have_run_;
+  bool waiting_for_run_;
+};
+
+class TestJob : public WorkerPoolJob {
+ public:
+  explicit TestJob(Callback0::Type* callback)
+      : callback_(callback),
+        run_on_worker_pool_event_(true /* manual reset */,
+                                  false /* not initially signalled */) {}
+
+  void SignalOnWorkerPool() {
+    run_on_worker_pool_event_.Signal();
+  }
+
+  using WorkerPoolJob::StartJob;
+  using WorkerPoolJob::CancelJob;
+  using WorkerPoolJob::canceled;
+  using WorkerPoolJob::is_running;
+
+ protected:
+  ~TestJob() {}
+
+ private:
+  virtual void RunJob() {
+    run_on_worker_pool_event_.Wait();
+  }
+
+  virtual void CompleteJob() {
+    callback_->Run();
+  }
+
+  Callback0::Type* const callback_;
+  WaitableEvent run_on_worker_pool_event_;
+};
+
+TEST(WorkerPoolJobTest, Simple) {
+  MessageLoop loop;
+  TestCallback callback;
+  scoped_refptr<TestJob> job(new TestJob(&callback));
+  job->StartJob();
+  EXPECT_TRUE(job->is_running());
+  job->SignalOnWorkerPool();
+  callback.Wait();
+  EXPECT_FALSE(job->canceled());
+  EXPECT_FALSE(job->is_running());
+}
+
+TEST(WorkerPoolJobTest, CancelOnWorker) {

[eroman, 2010/12/22 23:25:08]

I believe this test may result in a leak report.

Since we don't join on the worker thread, isn't it possible for TestJob to still
be referenced and running on the thread?

[willchan no longer on Chromium, 2010/12/24 00:47:34]

I do not believe that's how valgrind works.  I think it will look at the stack
variables for the worker thread and see that the object is still referenced. 
Otherwise, wouldn't we have a bunch of leaks for the getaddrinfo() objects on
worker threads?

[eroman, 2010/12/24 00:54:42]

Outstanding worker threads at shutdown causes leaks in valgrind.
This comes up all the time with UI tests in the context of DNS threads, and we
have particular suppressions for that.

If you can avoid it though, you don't want to tickle this in your own unittests.
See for example crbug.com/52459.

+  MessageLoop loop;
+
+  {
+    TestCallback callback;
+    scoped_refptr<TestJob> job(new TestJob(&callback));
+    job->StartJob();
+    job->CancelJob();
+    job->SignalOnWorkerPool();
+    EXPECT_TRUE(job->canceled());
+  }
+
+  // Try to catch any broken behavior.
+  MessageLoop::current()->RunAllPending();
+}
+
+TEST(WorkerPoolJobTest, CancelOnOrigin) {
+  MessageLoop loop;
+  {
+    TestCallback callback;
+    scoped_refptr<TestJob> job(new TestJob(&callback));
+    job->StartJob();
+    EXPECT_TRUE(job->is_running());
+    job->SignalOnWorkerPool();
+    job->CancelJob();
+    EXPECT_TRUE(job->canceled());
+  }
+
+  // Try to catch any broken behavior.
+  MessageLoop::current()->RunAllPending();

[eroman, 2010/12/22 23:25:08]

The timings are hard to reason about here as well. Seems possible we may still
end up destroying the MessageLoop while there is an outstanding task on it.

[willchan no longer on Chromium, 2010/12/24 00:47:34]

What would be wrong with that?  Under valgrind, the MessageLoop will delete the
outstanding tasks.  What kind of error are you worried about?

+}
+
+}  // namespace
+
+}  // namespace base