Support COM in SequencedWorkerPool. This will be used by some code that

Support COM in SequencedWorkerPool.  This will be used by some code that
currently uses WorkerPool instead.

Unlike base::Thread, here COM support does not extend to running a TYPE_UI
MessageLoop, since SequencedWorkerPool doesn't use MessageLoop.  I think* I
don't actually need that.

*I have no real idea.  :(

BUG=251774, 328135
TEST=none
R=darin@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=265078

[Peter Kasting, 2014-04-19 02:23:00]

I wish I better understood the interaction between Windows COM support and our
MessageLoops.  The COM support here is going to be for Windows API calls that
result in Windows spinning a nested message loop.  (See e.g. the callstack on
https://crash.corp.google.com/samples?q=custom_data.ChromeCrashProto.magic_si...
for a case where this happens today on the UI thread; this change is the first
step towards fixing this callstack under bug 328135.)  Does that imply anything
in particular about the suitability of SequencedWorkerPool for these operations?
 I'm hoping just adding ScopedCOMInitializer to call CoInitializeEx() is fine,
and I don't need anything else.

[darin (slow to review), 2014-04-19 04:49:07]

+ windows peeps

This seems OK to me, LGTM.

https://codereview.chromium.org/242513006/diff/1/base/threading/sequenced_wor...
File base/threading/sequenced_worker_pool.cc (right):

https://codereview.chromium.org/242513006/diff/1/base/threading/sequenced_wor...
base/threading/sequenced_worker_pool.cc:497:
scoped_ptr<win::ScopedCOMInitializer> com_initializer(
nit: why heap allocate? why bother with |new| and |scoped_ptr|?

[Peter Kasting, 2014-04-21 20:38:37]

https://codereview.chromium.org/242513006/diff/1/base/threading/sequenced_wor...
File base/threading/sequenced_worker_pool.cc (right):

https://codereview.chromium.org/242513006/diff/1/base/threading/sequenced_wor...
base/threading/sequenced_worker_pool.cc:497:
scoped_ptr<win::ScopedCOMInitializer> com_initializer(
On 2014/04/19 04:49:07, darin wrote:
> nit: why heap allocate? why bother with |new| and |scoped_ptr|?

Probably because I was copying code from elsewhere... you're right, this can
just be on the stack.  Fixed.

[Peter Kasting, 2014-04-21 21:27:03]

Committed patchset #2 manually as r265078 (presubmit successful).