Adds a SHUTDOWN_TASK_QUEUE and a PreShutdown api to the scheduler.

components/scheduler/child/scheduler_helper.cc

Index: components/scheduler/child/scheduler_helper.cc
diff --git a/components/scheduler/child/scheduler_helper.cc b/components/scheduler/child/scheduler_helper.cc
index 19e8d2b65120525765527af4775d9564d2590f51..348ddae5a5c518f2a419b939b0eb84f1b336c3a7 100644
--- a/components/scheduler/child/scheduler_helper.cc
+++ b/components/scheduler/child/scheduler_helper.cc
@@ -4,6 +4,7 @@
 
 #include "components/scheduler/child/scheduler_helper.h"
 
+#include "base/synchronization/waitable_event.h"
 #include "base/trace_event/trace_event.h"
 #include "base/trace_event/trace_event_argument.h"
 #include "components/scheduler/child/nestable_single_thread_task_runner.h"
@@ -34,6 +35,9 @@ SchedulerHelper::SchedulerHelper(
           QueueId::CONTROL_TASK_AFTER_WAKEUP_QUEUE)),
       default_task_runner_(
           task_queue_manager_->TaskRunnerForQueue(QueueId::DEFAULT_TASK_QUEUE)),
+      shutdown_task_runner_(task_queue_manager_->TaskRunnerForQueue(
+          QueueId::SHUTDOWN_TASK_QUEUE)),
+      total_task_queue_count_(total_task_queue_count),
       quiescence_monitored_task_queue_mask_(
           ((1ull << total_task_queue_count) - 1ull) &
           ~(1ull << QueueId::IDLE_TASK_QUEUE) &
@@ -97,6 +101,32 @@ SchedulerHelper::SchedulerHelperDelegate::SchedulerHelperDelegate() {
 SchedulerHelper::SchedulerHelperDelegate::~SchedulerHelperDelegate() {
 }
 
+void SchedulerHelper::PreShutdown() {

[Sami, 2015/04/23 13:14:03]

Can we make the client ensure that this is called on the right thread? We don't
really have this pattern for any other method here. It seems scary if unrelated
threads are trying to initiate shutdown on the target thread.

[alex clarke (OOO till 29th), 2015/04/23 17:34:32]

I was able to do this blink side instead.

[Sami, 2015/04/23 18:47:49]

Great, thanks.

+  TRACE_EVENT0(disabled_by_default_tracing_category_, "PreShutdown");
+  if (shutdown_task_runner_->BelongsToCurrentThread()) {
+    PreShutdownInternal(nullptr);
+  } else {
+    base::WaitableEvent completion(false, false);
+    shutdown_task_runner_->PostTask(
+        FROM_HERE, base::Bind(&SchedulerHelper::PreShutdownInternal,
+                              base::Unretained(this), &completion));
+    completion.Wait();
+  }
+}
+
+void SchedulerHelper::PreShutdownInternal(base::WaitableEvent* completion) {
+  TRACE_EVENT0(disabled_by_default_tracing_category_, "PreShutdownInternal");
+  CheckOnValidThread();
+  EndIdlePeriod();

[Sami, 2015/04/23 13:14:02]

Do we actually need to end the idle period? The idle tasks won't get run because
the queue is disabled?

[alex clarke (OOO till 29th), 2015/04/23 17:34:32]

Yes I think so because enable_next_long_idle_period_closure_ gets posted on the
control_task_runner_ as does end_idle_period_closure_ (but that's not such a big
deal).

[Sami, 2015/04/23 18:47:49]

We could just let those run. I don't think there should be any bad side effects.

[alex clarke (OOO till 29th), 2015/04/24 09:32:35]

The reason I wrote this patch in the first place is because I got a segfault in
a GC idle task running in the gap between WorkerThread::stop and the thread
actually getting shut down.  We need to stop idle tasks.  Simply disabling the
idle queue isn't enough because there often will be a
enable_next_long_idle_period_closure_ posted on the control queue which we don't
disable.

[Sami, 2015/04/24 10:38:40]

That sounds like an instance of the bug I was worried about: something goes and
changes the set of enabled queues after this task has run. I think we need to
guard against that in a more sound way. As we add new scheduling primitives it's
very easy to forget to account for them here.

[alex clarke (OOO till 29th), 2015/04/24 14:10:04]

Done.

+  task_queue_selector_->DisableQueue(QueueId::CONTROL_TASK_AFTER_WAKEUP_QUEUE);
+  task_queue_selector_->DisableQueue(QueueId::DEFAULT_TASK_QUEUE);
+  for (size_t i = TASK_QUEUE_COUNT; i < total_task_queue_count_; i++) {

[Sami, 2015/04/23 13:14:02]

Can we get a policy update that undoes all of this?

[alex clarke (OOO till 29th), 2015/04/23 17:34:32]

Yes, but only on the render thread where this isn't intended for use. I think
there is an argument that this should be specific to the worker scheduler, but
that's awkward to surface in blink since there's no worker specific WebThread.

[Sami, 2015/04/24 10:38:40]

Looks like my reply here got lost somehow: I don't think we can rely on the fact
that this only happens in a Worker here. Maybe we can isolate the selector so
that it becomes impossible to enable any additional queues after this function
has been called?

[alex clarke (OOO till 29th), 2015/04/24 14:10:04]

Done.

+    task_queue_selector_->DisableQueue(i);
+  }
+  if (completion)
+    completion->Signal();
+}
+
 void SchedulerHelper::Shutdown() {
   CheckOnValidThread();
   task_queue_manager_.reset();
@@ -114,6 +144,12 @@ scoped_refptr<SingleThreadIdleTaskRunner> SchedulerHelper::IdleTaskRunner() {
 }
 
 scoped_refptr<base::SingleThreadTaskRunner>
+SchedulerHelper::ShutdownTaskRunner() {
+  CheckOnValidThread();
+  return shutdown_task_runner_;
+}
+
+scoped_refptr<base::SingleThreadTaskRunner>
 SchedulerHelper::ControlTaskRunner() {
   return control_task_runner_;
 }
@@ -364,6 +400,8 @@ const char* SchedulerHelper::TaskQueueIdToString(QueueId queue_id) {
       return "default_tq";
     case IDLE_TASK_QUEUE:
       return "idle_tq";
+    case SHUTDOWN_TASK_QUEUE:
+      return "shutdown_tq";
     case CONTROL_TASK_QUEUE:
       return "control_tq";
     case CONTROL_TASK_AFTER_WAKEUP_QUEUE: