Introduce TaskRunnerHelper::get()

third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp

Index: third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
diff --git a/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp b/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
index 55719983cdee79e401b0e91401cb498f910475d0..5d6de3e72d2db434f4f3ed1cbe423ab34454c8f7 100644
--- a/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
+++ b/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
@@ -13,6 +13,49 @@
 
 namespace blink {
 
+WebTaskRunner* TaskRunnerHelper::get(TaskType type, LocalFrame* frame)
+{
+    // TODO(haraken): Optimize the mapping from TaskTypes to task runners.
+    switch (type) {
+    case TaskType::DOMManipulation:
+    case TaskType::UserInteraction:
+    case TaskType::HistoryTraversal:
+    case TaskType::Embed:
+    case TaskType::MediaElementEvent:
+    case TaskType::CanvasBlobSerialization:
+    case TaskType::RemoteEvent:
+    case TaskType::WebSocket:

[kinuko, 2016/08/11 14:21:58]

IIRC some of WebSocket tasks are posted as loading tasks, this might cause
unwanted task reordering?

While introducing task types based on spec looks reasonable I'm slightly worried
that introducing this many task types at once might cause more confusion than
what we want to  achieve first (e.g. per-frame task scheduling).  Say, how do we
think about an internal task that could unblock multiple things that might fall
into multiple categories?

[Sami, 2016/08/11 14:52:46]

Good point -- we probably want to fix that.
I'm not sure what you mean by unblocking? Or did you just mean some task that
does, say, WebSocket and DOMManipulation work? I think that's a good point and
requires some amount of caution. I can think of two options:

1) Make sure those tasks can be safely reordered w.r.t. the
WebSocket/DOMManipulation task runners (and vice versa).

2) Introduce a barrier object that can be used to enforce serialization at the
expense of possible extra delays.

It might be that the right option is different depending on the subsystem.

(We might also want to do some fuzz testing with a scheduler that maximizes task
reordering to weed out bugs.) 

+    case TaskType::Microtask:
+    case TaskType::PostedMessage:
+    case TaskType::UnshippedPortMessage:
+    case TaskType::Timer:
+    case TaskType::Internal:
+        return frame ? frame->frameScheduler()->timerTaskRunner() : Platform::current()->currentThread()->getWebTaskRunner();
+    case TaskType::Networking:
+        return frame ? frame->frameScheduler()->loadingTaskRunner() : Platform::current()->currentThread()->getWebTaskRunner();
+    case TaskType::Unthrottled:
+        return frame ? frame->frameScheduler()->unthrottledTaskRunner() : Platform::current()->currentThread()->getWebTaskRunner();
+    default:
+        NOTREACHED();
+    }
+    return nullptr;
+}
+
+WebTaskRunner* TaskRunnerHelper::get(TaskType type, Document* document)
+{
+    return get(type, document ? document->frame() : nullptr);
+}
+
+WebTaskRunner* TaskRunnerHelper::get(TaskType type, ExecutionContext* executionContext)
+{
+    return get(type, executionContext && executionContext->isDocument() ? static_cast<Document*>(executionContext) : nullptr);
+}
+
+WebTaskRunner* TaskRunnerHelper::get(TaskType type, ScriptState* scriptState)
+{
+    return get(type, scriptState ? scriptState->getExecutionContext() : nullptr);
+}
+
 WebTaskRunner* TaskRunnerHelper::getUnthrottledTaskRunner(LocalFrame* frame)
 {
     return frame ? frame->frameScheduler()->unthrottledTaskRunner() : Platform::current()->currentThread()->getWebTaskRunner();