TaskScheduler: Remove base::ExecutionMode.

base/task_scheduler/scheduler_worker.cc

Index: base/task_scheduler/scheduler_worker.cc
diff --git a/base/task_scheduler/scheduler_worker.cc b/base/task_scheduler/scheduler_worker.cc
index 2851a8d43c0948e812bd6d693bded63c43a4d161..d1cc1b1b701064fc4eb34e1300f3ae1382a2c7f6 100644
--- a/base/task_scheduler/scheduler_worker.cc
+++ b/base/task_scheduler/scheduler_worker.cc
@@ -47,7 +47,7 @@ class SchedulerWorker::Thread : public PlatformThread::Delegate {
     // This is required as SequencedWorkerPool previously blindly CoInitialized
     // all of its threads.
     // TODO: Get rid of this broad COM scope and force tasks that care about a
-    // CoInitialized environment to request one (via an upcoming ExecutionMode).
+    // CoInitialized environment to request one (via an upcoming trait).

[robliao, 2016/10/31 19:19:59]

I thought we were keeping COM as an execution mode since they effectively make
the task runner single-threaded. Are we no longer doing this?

[fdoray, 2016/10/31 19:44:51]

From Gab in "Typed TaskRunners and child TaskRunners" discussion: "As for
SEQUENCED+COM, I guess it will always be single-threaded for now in the
background but that doesn't break the API contract so we don't need to ban it."

If someone knows that their tasks don't have to run on the same thread (e.g.
they make independent COM calls), I think we should let them choose the
appropriate execution mode. They don't have to know that we'll run all COM tasks
posted to the same pool on the same thread.

Does that make sense?

[robliao, 2016/10/31 19:50:46]

In the Sequenced+COM case, it would be unexpected for tasks to post to one COM
apartment and then later on post to another COM apartment. That effectively
makes the task runner single threaded.

The only signal we have from the caller on whether or not it's safe tear down
the apartment is to have the TaskRunner go away.

[fdoray, 2016/10/31 20:42:28]

Changed "upcoming trait" to "upcoming execution mode" since this is outside the
scope of this CL.

We should discuss COM tomorrow. Do one-off COM tasks exist? If so, I think it
makes sense to support base::PostTask(..., TaskTraits().WithCOM()).

     win::ScopedCOMInitializer com_initializer;
 #endif