Rename WorkerThread to WorkerScript

Rename WorkerThread to WorkerScript

"WorkerThread" sounds like a thread, but the current implementation
is more related to the script environment than thread. For example,
multiple CompositeWorkerThread instances share one backing thread.

This change renames the classes to increase the readability.

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=575532

[yhirano, 2016-02-23 22:52:09]

Description was changed from

==========
Rename WorkerThread to WorkerScript

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=
==========

to

==========
Rename WorkerThread to WorkerScript

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=575532
==========

[yhirano, 2016-02-23 22:52:10]

yhirano@chromium.org changed reviewers:
+ voldenm@gmail.com

[yhirano, 2016-02-23 22:52:29]

yhirano@chromium.org changed reviewers:
+ kinuko@chromium.org
- voldenm@gmail.com

[yhirano, 2016-02-23 23:03:26]

Description was changed from

==========
Rename WorkerThread to WorkerScript

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=575532
==========

to

==========
Rename WorkerThread to WorkerScript

"WorkerThread" sounds like a thread, but the current implementation
is more related to the script environment than thread. In fact,
a WorkerThread subclass, CompositeWorkerThread, is not corresponding
to a thread and multiple instances share one backing thread.

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=575532
==========

[yhirano, 2016-02-23 23:06:59]

Description was changed from

==========
Rename WorkerThread to WorkerScript

"WorkerThread" sounds like a thread, but the current implementation
is more related to the script environment than thread. In fact,
a WorkerThread subclass, CompositeWorkerThread, is not corresponding
to a thread and multiple instances share one backing thread.

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=575532
==========

to

==========
Rename WorkerThread to WorkerScript

"WorkerThread" sounds like a thread, but the current implementation
is more related to the script environment than thread. For example,
multiple CompositeWorkerThread instances share one backing thread.

This change renames the classes to increase the readability.

This change is a follow-up of https://codereview.chromium.org/1100413004.

BUG=575532
==========

[yhirano, 2016-02-23 23:12:17]

Hi, kinuko@, can you take a look? You reviewed
https://codereview.chromium.org/1100413004, so I think you're the right
reviewer.

cc: sadrul@, jochen@.

This change depends on https://codereview.chromium.org/1726903002/.

I'm planning to decouple thread-related part from WorkerScript and create a new
WorkerThread class in the future.

[haraken, 2016-02-24 10:16:06]

Would it make more sense to rename WorkerThread to WorkerGlobalScopeProxy? I
think the relationship between WorkerThread and WorkerGlobalScope is similar to
the one between WindowProxy and DOMWindow.

[kinuko, 2016-02-24 12:54:51]

Some methods on WorkerThread are more for threading/run-loop related than
script-related, which makes me feel this renaming has some pros/cons.  Given
that renaming adds a lot of code churn I haven't been fully convinced that we
should rename this.

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/inspector/InspectorTraceEvents.cpp (right):

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/inspector/InspectorTraceEvents.cpp:781:
value->setDouble("workerScriptId", workerScript->platformThreadId());
We're setting platform thread ID here, workerScriptId probably doesn't make
sense.

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/inspector/WorkerThreadDebugger.h (right):

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/inspector/WorkerThreadDebugger.h:40: class
WorkerThreadDebugger final : public ThreadDebugger {
Hmm.. should this be WorkerScriptDebugger?

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/WorkerScript.h (right):

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkerScript.h:72: virtual void
willStopWorkerScript();
Embedder / content expects these are actually called when a thread is started
and before it gets stopped (as they're typically used for initializing /
deleting thread-local objects), I think this renaming wouldn't make much sense.

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkerScript.h:87: bool
isCurrentThread();
This method feels a bit misplaced now.

https://codereview.chromium.org/1728803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkerScript.h:110: void
didRunDebuggerTasks();
Some of these methods that post a task / run a debugger task feel less
irrelevant now?

[kinuko, 2016-02-24 13:02:38]

We already have WorkerGlobalScopeProxy (and ServiceWorkerGlobalScopeProxy for
SW), which bridges between Worker object (or browser-side code for SW) and
WorkerGlobalScope.  We could possibly rename / refactor the existing proxy code
too (as they're not super cleanly designed either) but we'll have pileups.

yhirano@ wrote:
> I'm planning to decouple thread-related part from WorkerScript and create a
new
> WorkerThread class in the future.

If we could cleanly separate seemingly more threading-related part to the new
class I could be convinced.

[yhirano, 2016-02-26 22:14:01]

On 2016/02/24 13:02:38, kinuko wrote:
> yhirano@ wrote:
> > I'm planning to decouple thread-related part from WorkerScript and create a
> new
> > WorkerThread class in the future.
> 
> If we could cleanly separate seemingly more threading-related part to the new
> class I could be convinced.

I uploaded https://codereview.chromium.org/1733353004/.

[kinuko, 2016-03-02 07:57:50]

On 2016/02/26 22:14:01, yhirano wrote:
> On 2016/02/24 13:02:38, kinuko wrote:
> > yhirano@ wrote:
> > > I'm planning to decouple thread-related part from WorkerScript and create
a
> > new
> > > WorkerThread class in the future.
> > 
> > If we could cleanly separate seemingly more threading-related part to the
new
> > class I could be convinced.
> 
> I uploaded https://codereview.chromium.org/1733353004/.

Took a look at the other patch, I think it works for me.