Refactoring WorkletThreadBackingHolder with template pattern

Refactoring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)

Committed: https://crrev.com/b6660c6d8bb364f1122c94db9f19a98f38b42a7a
Cr-Commit-Position: refs/heads/master@{#428131}

[hongchan, 2016-10-18 20:12:03]

hongchan@chromium.org changed reviewers:
+ haraken@chromium.org, nhiroki@chromium.org

[hongchan, 2016-10-18 20:12:04]

PTAL at the overall design and let me know what you think.

[hongchan, 2016-10-18 21:55:55]

The CQ bit was checked by hongchan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-18 21:56:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-18 22:10:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-18 22:10:25]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[nhiroki, 2016-10-19 01:36:49]

Thank you for working on this :)

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h
(right):

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:34: //
instance of DereivedWorkletThreadHolder (i.e. AnimationWorkletThreadHolder,
s/Dereived/Derived/

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:61:
DCHECK_EQ(nullptr, s_holderInstance);
DCHECK(!s_holderInstance)?

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:78:
DEFINE_THREAD_SAFE_STATIC_LOCAL(Mutex, holderMutex, new Mutex);
Just to confirm: Each template class instance's holderInstanceMutex() has its
own function-level static variable |holderMutex|, so this isn't shared among
AnimationWorkletThreadHolder and AudioWorkletThreadHolder, right?

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:109: static
DerivedWorkletThreadHolder* s_holderInstance;
Just to confirm: Each template class instance has its own static member
|s_holderInstance|, so this isn't shared among AnimationWorkletThreadHolder and
AudioWorkletThreadHolder, right?

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/m...
File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp (right):

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/m...
third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp:28: : public
WorkletThreadHolder<AudioWorkletThreadHolder> {
I'd prefer to avoid class inheritance as much as possible because WorkerThread
classes already have deep inheritance hierarchy. Instead of inheritance, how
about like this?

1) Make WorkletThreadHolder receive client's WorkerThread name
(AudioWorkletThread) as a template parameter instead of a derived class name
(AudioWorkletThreadHolder).

  WorkletThreadHolder<AudioWorkletThreadHolder>
    -> WorkletThreadHolder<AudioWorkletThread>

2) Define createWorkletThreadHolder() on AudioWorkletThread like this:

  static WorkletThreadHolder<AudioWorkletThread>*
AudioWorkletThread::createWorkletThreadHolder(std::unique_ptr<WorkerBackingThread>
backingThread = nullptr) { ... }

3) Make
WorkletThreadHolder<AudioWorkletThread>::ensureInstance()/createForTest() call
AudioWorkletThread::createWorkletThreadHolder() instead of the derived class's
ctor.

WDYT?

[hongchan, 2016-10-24 18:39:21]

nhiroki@

Unfortunately, I am not sure how to make it work with your suggestion. They are
not supposed to be initialized/constructed at the same time - I believe the
worklet thread holder is design to be initialized lazily.

Applying/inheriting forces two objects to be initialized through the single
construction process, and I think this makes our goal of using the template
directly to AudioWorkletThread difficult. Perhaps I am not understanding your
intention correctly, so please advise.

The PS2 compiles, but it causes seg fault in the first unit test. (Basic)

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h
(right):

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:34: //
instance of DereivedWorkletThreadHolder (i.e. AnimationWorkletThreadHolder,
On 2016/10/19 01:36:49, nhiroki wrote:
> s/Dereived/Derived/

Done.

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:61:
DCHECK_EQ(nullptr, s_holderInstance);
On 2016/10/19 01:36:49, nhiroki wrote:
> DCHECK(!s_holderInstance)?

Done.

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:78:
DEFINE_THREAD_SAFE_STATIC_LOCAL(Mutex, holderMutex, new Mutex);
On 2016/10/19 01:36:49, nhiroki wrote:
> Just to confirm: Each template class instance's holderInstanceMutex() has its
> own function-level static variable |holderMutex|, so this isn't shared among
> AnimationWorkletThreadHolder and AudioWorkletThreadHolder, right?

Yes. That is the intention. The same type/class will share the static instance,
but not with the different types/classes.

https://codereview.chromium.org/2432543002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/workers/WorkletBackingThreadHolder.h:109: static
DerivedWorkletThreadHolder* s_holderInstance;
On 2016/10/19 01:36:49, nhiroki wrote:
> Just to confirm: Each template class instance has its own static member
> |s_holderInstance|, so this isn't shared among AnimationWorkletThreadHolder
and
> AudioWorkletThreadHolder, right?

Yes. As discussed above.

[nhiroki, 2016-10-25 04:29:24]

On 2016/10/24 18:39:21, hongchan wrote:
> nhiroki@
> 
> Unfortunately, I am not sure how to make it work with your suggestion. They
are
> not supposed to be initialized/constructed at the same time - I believe the
> worklet thread holder is design to be initialized lazily.
> 
> Applying/inheriting forces two objects to be initialized through the single
> construction process, and I think this makes our goal of using the template
> directly to AudioWorkletThread difficult. Perhaps I am not understanding your
> intention correctly, so please advise.

I copied this patch and tweaked it to check feasibility:
https://codereview.chromium.org/2448863002/

Can you see this? Note that I haven't tested it well, so there may be a corner
case.

> The PS2 compiles, but it causes seg fault in the first unit test. (Basic)

It looks like that s_threadHolderInstance is never created.

[hongchan, 2016-10-25 16:29:17]

The CQ bit was checked by hongchan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-25 16:29:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-25 16:38:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-25 16:38:11]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[hongchan, 2016-10-25 16:39:38]

Description was changed from

==========
Refacotring WorkletThreadBackingHolder with template pattern

* WIP : DO NOT SUBMIT *

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

to

==========
Refacotring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

[hongchan, 2016-10-25 19:50:33]

On 2016/10/25 04:29:24, nhiroki (slow until Oct. 31) wrote:
> On 2016/10/24 18:39:21, hongchan wrote:
> > nhiroki@
> > 
> > Unfortunately, I am not sure how to make it work with your suggestion. They
> are
> > not supposed to be initialized/constructed at the same time - I believe the
> > worklet thread holder is design to be initialized lazily.
> > 
> > Applying/inheriting forces two objects to be initialized through the single
> > construction process, and I think this makes our goal of using the template
> > directly to AudioWorkletThread difficult. Perhaps I am not understanding
your
> > intention correctly, so please advise.
> 
> I copied this patch and tweaked it to check feasibility:
> https://codereview.chromium.org/2448863002/
> 
> Can you see this? Note that I haven't tested it well, so there may be a corner
> case.
> 
> > The PS2 compiles, but it causes seg fault in the first unit test. (Basic)
> 
> It looks like that s_threadHolderInstance is never created.

The ASAN says unit tests are leaking. I am looking into the issue, but any help
would be appreciated - I am not familiar with the worker infrastructure.

[nhiroki, 2016-10-25 22:39:34]

https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp (left):

https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp:52: new
AudioWorkletThreadHolder(WorkerBackingThread::createForTest(
Ah, we removed this part :p

In unit tests, we need to create WorkerBackingThread by
WorkerBackingThread::createForTest(). This suppresses leak reports. See
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/workers/W...

[hongchan, 2016-10-25 23:04:55]

On 2016/10/25 22:39:34, nhiroki (slow until Oct. 31) wrote:
>
https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp (left):
> 
>
https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp:52: new
> AudioWorkletThreadHolder(WorkerBackingThread::createForTest(
> Ah, we removed this part :p
> 
> In unit tests, we need to create WorkerBackingThread by
> WorkerBackingThread::createForTest(). This suppresses leak reports. See
>
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/workers/W...

Good catch! I'll try to fix it.

One issue: this template class also needs to support the AnimationWorkletThread.
The instantiation is a bit different - AnimationWorklet runs off the compositor
thread. The current ensureInstance() method assumes that we create a worker
backing thread when it's needed, but for the AnimationWorklet we just use the
existing compositor thread. I guess we can always pass
platform()->compositorThread() to ensureInstance(), but not sure if it's ideal.

[nhiroki, 2016-10-26 00:08:21]

On 2016/10/25 23:04:55, hongchan wrote:
> One issue: this template class also needs to support the
AnimationWorkletThread.
> The instantiation is a bit different - AnimationWorklet runs off the
compositor
> thread. The current ensureInstance() method assumes that we create a worker
> backing thread when it's needed, but for the AnimationWorklet we just use the
> existing compositor thread. I guess we can always pass
> platform()->compositorThread() to ensureInstance(), but not sure if it's
ideal.

I'm fine with always passing compositorThread().

[haraken, 2016-10-26 07:38:22]

I think this is going in a right direction.

[nhiroki, 2016-10-26 08:08:18]

https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp (right):

https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp:70: void
AudioWorkletThread::clearSharedBackingThread() {
Copied from https://codereview.chromium.org/2448863002/

On 2016/10/26 07:41:49, haraken wrote:
> 
> Are you sure that this method is called?
> 
> As far as I look at the leak log, it looks like WorkletGlobalScope is not
> released.

Good point. It looks like that this is correctly called in unit tests, but it's
not called in production codes.

[hongchan, 2016-10-26 18:35:38]

On 2016/10/26 08:08:18, nhiroki (slow until Oct. 31) wrote:
>
https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp
(right):
> 
>
https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp:70: void
> AudioWorkletThread::clearSharedBackingThread() {
> Copied from https://codereview.chromium.org/2448863002/
> 
> On 2016/10/26 07:41:49, haraken wrote:
> > 
> > Are you sure that this method is called?
> > 
> > As far as I look at the leak log, it looks like WorkletGlobalScope is not
> > released.
> 
> Good point. It looks like that this is correctly called in unit tests, but
it's
> not called in production codes.

We don't have the actual usage of this class in the production code yet. Right?

[hongchan, 2016-10-26 21:17:16]

The CQ bit was checked by hongchan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 21:17:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-26 21:32:42]

On 2016/10/26 18:35:38, hongchan wrote:
> On 2016/10/26 08:08:18, nhiroki (slow until Oct. 31) wrote:
> >
>
https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp
> (right):
> > 
> >
>
https://codereview.chromium.org/2432543002/diff/60001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.cpp:70: void
> > AudioWorkletThread::clearSharedBackingThread() {
> > Copied from https://codereview.chromium.org/2448863002/
> > 
> > On 2016/10/26 07:41:49, haraken wrote:
> > > 
> > > Are you sure that this method is called?
> > > 
> > > As far as I look at the leak log, it looks like WorkletGlobalScope is not
> > > released.
> > 
> > Good point. It looks like that this is correctly called in unit tests, but
> it's
> > not called in production codes.
> 
> We don't have the actual usage of this class in the production code yet.
Right?

Ah, OK. I assumed we have layout tests for AudioWorklet.

[hongchan, 2016-10-26 22:27:48]

The CQ bit was checked by hongchan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 22:28:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[hongchan, 2016-10-26 23:26:16]

The CQ bit was checked by hongchan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 23:26:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[hongchan, 2016-10-26 23:28:38]

hongchan@chromium.org changed reviewers:
+ ikilpatrick@chromium.org, rtoy@chromium.org

[hongchan, 2016-10-26 23:28:38]

PTAL. I believe the CL is ready for the actual review.

- Applying the new template to AbstractAnimationWorkletThread
- Renaming the template class file to WorkletThreadHolder.h
- Removing unnecessary files/codes after the refactoring.

[nhiroki, 2016-10-27 00:03:35]

LGTM! Thank you for working on this :)

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/workers/WorkletThreadHolder.h (right):

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:17: class
WaitableEvent;
There are header inclusions for these classes.

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:31:
BlinkGC::ThreadHeapMode ThreadHeapMode) {
s/ThreadHeapMode/threadHeapMode/

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:51:
BlinkGC::ThreadHeapMode ThreadHeapMode) {
s/ThreadHeapMode/threadHeapMode/

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:53:
DCHECK_EQ(nullptr, s_threadHolderInstance);
DCHECK(s_threadHolderInstace) would be simpler

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.h (right):

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.h:51: explicit
AudioWorkletThread(PassRefPtr<WorkerLoaderProxy>,
Can you remove 'explicit'?

[nhiroki, 2016-10-27 00:04:20]

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/workers/WorkletThreadHolder.h (right):

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:53:
DCHECK_EQ(nullptr, s_threadHolderInstance);
On 2016/10/27 00:03:35, nhiroki (slow until Oct. 31) wrote:
> DCHECK(s_threadHolderInstace) would be simpler

DCHECK(!s_threadHolderInstace)

[commit-bot: I haz the power, 2016-10-27 00:40:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 00:40:04]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-10-27 01:23:19]

LGTM

[ikilpatrick, 2016-10-27 16:09:31]

lgtm

[hongchan, 2016-10-27 17:31:07]

Thanks for the review!

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/workers/WorkletThreadHolder.h (right):

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:17: class
WaitableEvent;
On 2016/10/27 00:03:35, nhiroki (slow until Oct. 31) wrote:
> There are header inclusions for these classes.

Done.

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:31:
BlinkGC::ThreadHeapMode ThreadHeapMode) {
On 2016/10/27 00:03:35, nhiroki (slow until Oct. 31) wrote:
> s/ThreadHeapMode/threadHeapMode/

Done.

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:51:
BlinkGC::ThreadHeapMode ThreadHeapMode) {
On 2016/10/27 00:03:35, nhiroki (slow until Oct. 31) wrote:
> s/ThreadHeapMode/threadHeapMode/

Done.

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/workers/WorkletThreadHolder.h:53:
DCHECK_EQ(nullptr, s_threadHolderInstance);
On 2016/10/27 00:04:20, nhiroki (slow until Oct. 31) wrote:
> On 2016/10/27 00:03:35, nhiroki (slow until Oct. 31) wrote:
> > DCHECK(s_threadHolderInstace) would be simpler
> 
> DCHECK(!s_threadHolderInstace)

Done.

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.h (right):

https://codereview.chromium.org/2432543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/webaudio/AudioWorkletThread.h:51: explicit
AudioWorkletThread(PassRefPtr<WorkerLoaderProxy>,
On 2016/10/27 00:03:35, nhiroki (slow until Oct. 31) wrote:
> Can you remove 'explicit'?

Done.

[hongchan, 2016-10-27 17:31:15]

The CQ bit was checked by hongchan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-27 17:31:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Raymond Toy, 2016-10-27 18:52:36]

lgtm for webaudio parts.

Please fix the typo in the description ("Refacotring")

[commit-bot: I haz the power, 2016-10-27 19:02:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 19:03:01]

Dry run: This issue passed the CQ dry run.

[hongchan, 2016-10-27 20:42:39]

Description was changed from

==========
Refacotring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

to

==========
Refactoring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

[hongchan, 2016-10-27 20:42:49]

The CQ bit was checked by hongchan@chromium.org

[hongchan, 2016-10-27 20:42:50]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, ikilpatrick@chromium.org, nhiroki@chromium.org
Link to the patchset: https://codereview.chromium.org/2432543002/#ps140001
(title: "Fixing typos")

[commit-bot: I haz the power, 2016-10-27 20:43:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 20:49:33]

Description was changed from

==========
Refactoring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

to

==========
Refactoring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

[commit-bot: I haz the power, 2016-10-27 20:49:35]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-10-27 20:51:49]

Description was changed from

==========
Refactoring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)
==========

to

==========
Refactoring WorkletThreadBackingHolder with template pattern

The current design of WorkletBackingThreadHolder has too many duplicated
components. Refactor it with the template pattern.

BUG=657101
TEST=NONE (The CL passes AudioWorkletThread unit tests.)

Committed: https://crrev.com/b6660c6d8bb364f1122c94db9f19a98f38b42a7a
Cr-Commit-Position: refs/heads/master@{#428131}
==========

[commit-bot: I haz the power, 2016-10-27 20:51:51]

Patchset 8 (id:??) landed as
https://crrev.com/b6660c6d8bb364f1122c94db9f19a98f38b42a7a
Cr-Commit-Position: refs/heads/master@{#428131}