Fix TaskScheduler initialization in remoting processes.

remoting/client/ios/app_runtime.cc

 // Copyright 2017 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 "remoting/client/ios/app_runtime.h"
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
 #include "base/logging.h"
 #include "base/memory/ptr_util.h"
@@ skipping 13 matching lines @@
 #include "remoting/protocol/negotiating_client_authenticator.h"
 #include "remoting/protocol/transport_context.h"
 #include "remoting/signaling/delegating_signal_strategy.h"
 
 namespace remoting {
 namespace ios {
 
 AppRuntime::AppRuntime() {
   // TODO(sergeyu): Consider adding separate pools for different task classes.
   const int kMaxBackgroundThreads = 5;
-  if (TaskScheduler::GetInstance()) {
+  if (!TaskScheduler::GetInstance()) {
     // Make sure TaskScheduler is initialized.
     base::TaskScheduler::CreateAndSetSimpleTaskScheduler(kMaxBackgroundThreads);
   }
 
   // TODO(sergeyu): AppRuntime is not singleton, but it owns MessageLoop for the
   // current thread. This means that it's not safe to create multiple AppRuntime
   // instances on the same thread. AppRuntime should be a singleton, or this
   // code needs to be moved somewhere else.
   if (!base::MessageLoop::current()) {
     ui_loop_.reset(new base::MessageLoopForUI());
     base::MessageLoopForUI::current()->Attach();
   } else {
     ui_loop_.reset(base::MessageLoopForUI::current());
   }
   runtime_ = ChromotingClientRuntime::Create(ui_loop_.get());
 }
 
 AppRuntime::~AppRuntime() {
   // TODO(nicholss): Shutdown the app.

[fdoray, 2017/02/08 13:22:44]

Since multiple AppRuntimes can live in the same process, it would be incorrect
to shutdown TaskScheduler here. It's not so bad, it just means that shutdown
behaviors won't be honored
https://cs.chromium.org/chromium/src/base/task_scheduler/task_traits.h?l=41

 }
 
 }  // namespace ios
 }  // namespace remoting