Hook up the SequencedWorkerPool to the browser thread.

Hook up the SequencedWorkerPool to the browser thread.

[re-land of 116816 http://codereview.chromium.org/9065009]

This does some refactoring of the static data in the browser thread so we only have one global object instead of a bunch fo separate arrays.

It also hooks up the visited link master's I/O to use this new system as a proof of concept.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=118236

[brettw, 2012-01-07 23:56:03]

Re-land of the previous patch. I broke the unit tests for the visited link
system, which I modified to use the new worker pool. It turns out there was
always a race condition on this test (the creation of the second visited link
master races with the I/O on the file thread) but for some reason the timings
always worked out in our favor. With my changes, somehow I tickled this balance.

The original patch is patch set 1, so you can see the changes. I had to add a
Flush() call to flush the worker tasks.

[jam, 2012-01-08 23:04:22]

http://codereview.chromium.org/9124033/diff/17001/base/threading/sequenced_wo...
File base/threading/sequenced_worker_pool.h (right):

http://codereview.chromium.org/9124033/diff/17001/base/threading/sequenced_wo...
base/threading/sequenced_worker_pool.h:192: // Note that callin this will not
prevent other threads from posting work to
nit: calling

http://codereview.chromium.org/9124033/diff/17001/base/threading/sequenced_wo...
base/threading/sequenced_worker_pool.h:197: void Flush();
if this is only for testing, can we call this FlushForTesting

[brettw, 2012-01-18 00:16:25]

Comments addressed, new snap up.

[jam, 2012-01-18 18:43:58]

lgtm