compositor-worker: Initialize CW machinery plumbing to compositor and fire CW rAF callbacks.

third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThread.h

Index: third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThread.h
diff --git a/third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThread.h b/third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThread.h
index 224b1e88c505f9e9abfe23681aac291e123899e6..2eef10946894ca26f80543bf5fb44185be24d7a5 100644
--- a/third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThread.h
+++ b/third_party/WebKit/Source/modules/compositorworker/CompositorWorkerThread.h
@@ -22,7 +22,9 @@ public:
     WorkerBackingThread& workerBackingThread() override;
     bool shouldAttachThreadDebugger() const override { return false; }
 
+    static void ensureSharedBackingThread();
     static void resetSharedBackingThreadForTest();
+    static void clearSharedBackingThread();

[haraken, 2016/05/06 02:45:51]

+yhirano since he removed this method last week.

[yhirano, 2016/05/06 05:47:43]

Please add "ForTest" as this function is used only in tests.

Can you tell me why you need this function in CompositorWorkerThreadTest?

[flackr, 2016/05/06 18:15:07]

Ah, I didn't notice that you had removed the call to it from ModulesInitializer
when I merged it in. I was expecting to shut down the compositor worker thread
in ModulesInitializer::shutdown if it had been instantiated. I've now added this
to the patch.
Using CompositorWorkerThread::resetSharedBackingThreadForTest() causes a new
WorkerBackingThread to be created for the current "compositor thread". In
CompositorWorkerThreadTest, this thread is destroyed between tests so when we
call resetSharedBackingThreadForTest we try to post a task to this thread which
no longer exists.

[yhirano, 2016/05/09 03:15:31]

See https://codereview.chromium.org/1733353004/#msg77. It's more problematic
with this CL because at that time the code only allocated and destructed
WebThreadSupportingGC but now it runs the shutdown sequence.
Then I think you need to clear out BackingThreadHolder's state more deeply
because after calling clearSharedBackingThread() it's no longer usable. Calling
clearSharedBackingThread() means subsequent tests need to call
resetSharedBackingThreadForTest before using it and that is very confusing.

 
 protected:
     CompositorWorkerThread(PassRefPtr<WorkerLoaderProxy>, InProcessWorkerObjectProxy&, double timeOrigin);