[TimeZoneMonitor] Decouple renderer side impl from content to blink.

third_party/WebKit/Source/core/workers/WorkerBackingThread.h

Index: third_party/WebKit/Source/core/workers/WorkerBackingThread.h
diff --git a/third_party/WebKit/Source/core/workers/WorkerBackingThread.h b/third_party/WebKit/Source/core/workers/WorkerBackingThread.h
index f2cb1d8449a7d697c1a5e50da7da59169a3dc86f..46c4bab2cdb204b2a54277c653ebfe07e223c84c 100644
--- a/third_party/WebKit/Source/core/workers/WorkerBackingThread.h
+++ b/third_party/WebKit/Source/core/workers/WorkerBackingThread.h
@@ -69,6 +69,8 @@ class CORE_EXPORT WorkerBackingThread final {
 
   static void setRAILModeOnWorkerThreadIsolates(v8::RAILMode);
 
+  static void PostTaskToAllThreads(const base::Closure& closure);

[blundell, 2016/10/11 11:29:06]

Do the WorkerBackingThreads correspond exactly to workers in
content::PostTaskToAllWebWorkers()?

[blundell, 2016/10/11 11:29:06]

Could we reuse WorkerThread::workerThread() instead of creating parallel
functionality?

[leonhsl(Using Gerrit), 2016/10/12 03:55:55]

Seems multiple blink::WorkerThread correspond with 1 blink::WorkerBackingThread,
and content::WorkerThreadRegistry is tracking blink::WorkerBackingThread, so I'm
focusing on the latter one.

[leonhsl(Using Gerrit), 2016/10/12 03:55:55]

Yeah this has exactly the same effect with
content::WorkerThreadRegistry::PostTaskToAllThreads(), which is posting task to
all threads registered via blink::Platform API at
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/workers/W...
. 
As we want to do the same work inside blink, I maintains the worker threads via
a static blink::threadRunners(), maybe this is not proper way but I did not find
out how to enumerate all worker threads inside blink. #I noticed haraken@ has
helped asking nhiroki@ about this.

[nhiroki, 2016/10/12 06:20:20]

(This is not related to this CL and this looks like an issue of worker infra,
but let me leave a comment for the future)

Apparently, PostTaskToAllWebWorkers() doesn't post a task to
WorkerBackingThreads when they don't own a platform thread.
AnimationWorklet/AudioWorklet/CompositorWorker are such cases and these haven't
been shipped yet, so this is not a real problem. We may need to fix it before
shipping them.

=== Details ===

WorkerBackingThread creates and owns a dedicated platform thread for typical
workers, but it doesn't create a thread and instead borrows an existing platform
thread for some special workers (e.g. CompositorWorker is hosted on the existing
compositor thread[1]). Note that these special workers have NOT been shipped
yet.

WorkerThreadRegistry::PostTaskToAllThreads() posts a task to |task_runner_map_|.
This map is updated on WorkerThreadRegistry::DidStartCurrentWorkerThread()[2].
This is called from WorkerBackingThread::initialize() only when
WorkerBackingThread owns a platform thread[3].

[1]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/compos...
[2]
https://cs.chromium.org/chromium/src/content/child/worker_thread_registry.cc?...
[3]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/workers/W...

[nhiroki, 2016/10/12 06:32:46]

Filed an issue: https://bugs.chromium.org/p/chromium/issues/detail?id=655028

+
  private:
   WorkerBackingThread(const char* name,
                       bool shouldCallGCOnShutdown,