TaskScheduler: Remove base::ExecutionMode.

base/task_scheduler/scheduler_worker.cc

 // Copyright 2016 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/task_scheduler/scheduler_worker.h"
 
 #include <stddef.h>
 
 #include <utility>
 
@@ skipping 29 matching lines @@
 
     outer_->delegate_->OnMainEntry(outer_);
 
     // A SchedulerWorker starts out waiting for work.
     WaitForWork();
 
 #if defined(OS_WIN)
     // 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
 
     while (!outer_->task_tracker_->IsShutdownComplete() &&
            !outer_->should_exit_for_testing_.IsSet()) {
       DCHECK(outer_);
 
 #if defined(OS_MACOSX)
       mac::ScopedNSAutoreleasePool autorelease_pool;
 #endif
@@ skipping 214 matching lines @@
   thread_ = Thread::Create(this);
 }
 
 void SchedulerWorker::CreateThreadAssertSynchronized() {
   thread_lock_.AssertAcquired();
   CreateThread();
 }
 
 }  // namespace internal
 }  // namespace base