workers: Rename WorkerThread to WorkerScript.

workers: Rename WorkerThread to WorkerScript.

Now that WorkerThread is no longer responsible for managing the thread used for a
worker, rename WorkerThread to WorkerScript to better reflect the code (along with
relevant renames where applicable).

Detailed list of renames in the API:
 . WorkerThread -> WorkerScript
 . WorkerThreadStartupData -> WorkerScriptStartupData
 . WorkerGlobalScipe:
   . WorkerScriptController* script() -> WorkerScriptController* scriptController()
   . WorkerThread* thread() -> WorkerScript* script()
 . WorkerInspectorProxy:
   . workerThreadCreated() -> workerScriptCreated()
   . workerThreadTerminated() -> workerScriptTerminated()
 . WorkerMessagingProxy:
   . createWorkerThread() -> createWorkerScript()
   . workerThreadCreated() -> workerScriptCreated()
   . workerThreadTerminated() -> workerScriptTerminated()
 . WorkerReportingProxy:
   . workerThreadTerminated() -> workerScriptTerminated()

Subsequent CLs will rename SharedWorkerThread, DedicatedWorkerThread et. al. to
SharedWorkerScript, DedicatedWorkerScript etc.

BUG=436952

[sadrul, 2015-05-04 23:57:38]

sadrul@chromium.org changed reviewers:
+ jochen@chromium.org, kinuko@chromium.org

[sadrul, 2015-05-04 23:57:39]

Hi. As discussed in https://codereview.chromium.org/1100413004/, this does some
of the WorkerThread -> WorkerScript renames. I want to do the renames for
Shared, Dedicated etc. workers in a separate CL to keep this easier to review
(but happy to do them in this CL if that makes more sense to you).

[kinuko, 2015-05-08 01:33:22]

lgtm

https://codereview.chromium.org/1115923002/diff/40001/Source/core/dom/Executi...
File Source/core/dom/ExecutionContext.cpp (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/core/dom/Executi...
Source/core/dom/ExecutionContext.cpp:40: #include "core/workers/WorkerScript.h"
not directly related to your CL, but is this include needed?

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Ded...
File Source/core/workers/DedicatedWorkerThread.h (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Ded...
Source/core/workers/DedicatedWorkerThread.h:41: class DedicatedWorkerThread
final : public WorkerScript {
nit: can we have TODO for renaming this (to unconfuse readers)

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Sha...
File Source/core/workers/SharedWorkerThread.h (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Sha...
Source/core/workers/SharedWorkerThread.h:41: class CORE_EXPORT
SharedWorkerThread : public WorkerScript {
ditto

https://codereview.chromium.org/1115923002/diff/40001/Source/modules/servicew...
File Source/modules/serviceworkers/ServiceWorkerThread.h (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/modules/servicew...
Source/modules/serviceworkers/ServiceWorkerThread.h:41: class MODULES_EXPORT
ServiceWorkerThread final : public WorkerScript {
ditto

[sadrul, 2015-05-08 02:08:00]

https://codereview.chromium.org/1115923002/diff/40001/Source/core/dom/Executi...
File Source/core/dom/ExecutionContext.cpp (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/core/dom/Executi...
Source/core/dom/ExecutionContext.cpp:40: #include "core/workers/WorkerScript.h"
On 2015/05/08 01:33:21, kinuko wrote:
> not directly related to your CL, but is this include needed?

Good catch. This doesn't actually seem to be used here. Removed.

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Ded...
File Source/core/workers/DedicatedWorkerThread.h (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Ded...
Source/core/workers/DedicatedWorkerThread.h:41: class DedicatedWorkerThread
final : public WorkerScript {
On 2015/05/08 01:33:22, kinuko wrote:
> nit: can we have TODO for renaming this (to unconfuse readers)

Done.

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Sha...
File Source/core/workers/SharedWorkerThread.h (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/core/workers/Sha...
Source/core/workers/SharedWorkerThread.h:41: class CORE_EXPORT
SharedWorkerThread : public WorkerScript {
On 2015/05/08 01:33:22, kinuko wrote:
> ditto

Done.

https://codereview.chromium.org/1115923002/diff/40001/Source/modules/servicew...
File Source/modules/serviceworkers/ServiceWorkerThread.h (right):

https://codereview.chromium.org/1115923002/diff/40001/Source/modules/servicew...
Source/modules/serviceworkers/ServiceWorkerThread.h:41: class MODULES_EXPORT
ServiceWorkerThread final : public WorkerScript {
On 2015/05/08 01:33:22, kinuko wrote:
> ditto

Done.

[haraken, 2015-05-08 02:10:17]

bindings LGTM

[yurys, 2015-05-08 09:27:23]

yurys@chromium.org changed reviewers:
+ yurys@chromium.org

[yurys, 2015-05-08 09:27:24]

Why is WorkerScript a more appropriate name than WorkerThread for an object that
has methods we normally find on threads but no on scripts: start/terminate
execution, post task, enter nested message loop?

[kinuko, 2015-05-08 12:08:12]

On 2015/05/08 09:27:24, yurys wrote:
> Why is WorkerScript a more appropriate name than WorkerThread for an object
that
> has methods we normally find on threads but no on scripts: start/terminate
> execution, post task, enter nested message loop?

WorkerThread no longer really represents a thread as it might be attached to
multiple threads and we're afraid that calling it a 'thread' would be pretty
confusing.  I do think that having methods like 'start/terminate execution',
'post task' are totally fine on the new class name (we have similar concepts on
ExecutionContext / GlobalScope etc). For the methods for entering nested message
loop I had the same concern (they look a bit misplaced), but what they are doing
is not really thread related either.

[kinuko, 2015-05-08 12:09:52]

(Took another look at WorkerScript interface)

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
File Source/core/workers/WorkerScript.h (right):

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
Source/core/workers/WorkerScript.h:86: bool isCurrentThread();
This method looks a bit strange now. runsOnCurrentScriptThread() ?

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
Source/core/workers/WorkerScript.h:104: void didLeaveNestedLoop();
The comment for these methods needs to be updated. Also as yurys writes these
methods may look a bit misplaced with the new class name. Renaming them may
help? (No better alternative idea though)

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
Source/core/workers/WorkerScript.h:109: // Number of active worker threads.
Please update this comment.

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
Source/core/workers/WorkerScript.h:112: PlatformThreadId platformThreadId();
This method looks a bit strange now. getCurrentThreadId() ?

[yurys, 2015-05-08 13:35:29]

On 2015/05/08 12:08:12, kinuko wrote:
> On 2015/05/08 09:27:24, yurys wrote:
> > Why is WorkerScript a more appropriate name than WorkerThread for an object
> that
> > has methods we normally find on threads but no on scripts: start/terminate
> > execution, post task, enter nested message loop?
> 
> WorkerThread no longer really represents a thread as it might be attached to
> multiple threads and we're afraid that calling it a 'thread' would be pretty
> confusing.
Does it mean that instance of such class may hop from one worker thread to
another? This would break inspector assumptions that all worker tasks are
executed on one thread. Can you elaborate on this?


> I do think that having methods like 'start/terminate execution',
> 'post task' are totally fine on the new class name (we have similar concepts
on
> ExecutionContext / GlobalScope etc).
Correct. Moreover, we already have WorkerGlobalScope that implements
ExecutionContext for worker. Unlike WorkerThread it is unclear from the new name
what the responsibilities of WorkerScript compared to e.g.
WorkerScriptController or WorkerGlobalScope are.

> For the methods for entering nested message
> loop I had the same concern (they look a bit misplaced), but what they are
doing
> is not really thread related either.
Normally it is a thread that runs message loop and executes tasks, which
perfectly fits current name of this class. Maybe we should first extract such
methods into a separate class?

[kinuko, 2015-05-08 13:54:39]

On 2015/05/08 13:35:29, yurys wrote:
> On 2015/05/08 12:08:12, kinuko wrote:
> > On 2015/05/08 09:27:24, yurys wrote:
> > > Why is WorkerScript a more appropriate name than WorkerThread for an
object
> > that
> > > has methods we normally find on threads but no on scripts: start/terminate
> > > execution, post task, enter nested message loop?
> > 
> > WorkerThread no longer really represents a thread as it might be attached to
> > multiple threads and we're afraid that calling it a 'thread' would be pretty
> > confusing.
> Does it mean that instance of such class may hop from one worker thread to
> another? This would break inspector assumptions that all worker tasks are
> executed on one thread. Can you elaborate on this?

sadrul@ should be able to answer to this.  (In my understanding the instance
does not hop from one thread to another (this would not work in current blink),
but one thread may host multiple instances of such class.)

> > I do think that having methods like 'start/terminate execution',
> > 'post task' are totally fine on the new class name (we have similar concepts
> on
> > ExecutionContext / GlobalScope etc).
> Correct. Moreover, we already have WorkerGlobalScope that implements
> ExecutionContext for worker. Unlike WorkerThread it is unclear from the new
name
> what the responsibilities of WorkerScript compared to e.g.
> WorkerScriptController or WorkerGlobalScope are.

It'd provide 1:1 interface (e.g. start and terminate) to a worker script
execution (which hosts a WorkerGlobalScope on a worker thread), and that's where
this name comes from.  We're absolutely open to other suggestions though, I
agree that the term 'script' may sound a bit vague in this context.

> > For the methods for entering nested message
> > loop I had the same concern (they look a bit misplaced), but what they are
> doing
> > is not really thread related either.
> Normally it is a thread that runs message loop and executes tasks, which
> perfectly fits current name of this class. Maybe we should first extract such
> methods into a separate class?

Yup sounds good.

[yurys, 2015-05-08 14:00:18]

On 2015/05/08 13:54:39, kinuko wrote:
> On 2015/05/08 13:35:29, yurys wrote:
> > On 2015/05/08 12:08:12, kinuko wrote:
> > > On 2015/05/08 09:27:24, yurys wrote:
> > > > Why is WorkerScript a more appropriate name than WorkerThread for an
> object
> > > that
> > > > has methods we normally find on threads but no on scripts:
start/terminate
> > > > execution, post task, enter nested message loop?
> > > 
> > > WorkerThread no longer really represents a thread as it might be attached
to
> > > multiple threads and we're afraid that calling it a 'thread' would be
pretty
> > > confusing.
> > Does it mean that instance of such class may hop from one worker thread to
> > another? This would break inspector assumptions that all worker tasks are
> > executed on one thread. Can you elaborate on this?
> 
> sadrul@ should be able to answer to this.  (In my understanding the instance
> does not hop from one thread to another (this would not work in current
blink),
> but one thread may host multiple instances of such class.)
> 
The latter will break worker debugger since we assume that there is one worker
context per isolate on worker thread.

@sadrul: can you shed some light on this?


> > > I do think that having methods like 'start/terminate execution',
> > > 'post task' are totally fine on the new class name (we have similar
concepts
> > on
> > > ExecutionContext / GlobalScope etc).
> > Correct. Moreover, we already have WorkerGlobalScope that implements
> > ExecutionContext for worker. Unlike WorkerThread it is unclear from the new
> name
> > what the responsibilities of WorkerScript compared to e.g.
> > WorkerScriptController or WorkerGlobalScope are.
> 
> It'd provide 1:1 interface (e.g. start and terminate) to a worker script
> execution (which hosts a WorkerGlobalScope on a worker thread), and that's
where
> this name comes from.  We're absolutely open to other suggestions though, I
> agree that the term 'script' may sound a bit vague in this context.
> 
WorkerThread sounds good enough to me (at least better than WorkerScript if we
leave current interface of the class). It is backed by a platform thread but
that's expected in blink, isn't it?


> > > For the methods for entering nested message
> > > loop I had the same concern (they look a bit misplaced), but what they are
> > doing
> > > is not really thread related either.
> > Normally it is a thread that runs message loop and executes tasks, which
> > perfectly fits current name of this class. Maybe we should first extract
such
> > methods into a separate class?
> 
> Yup sounds good.

[kinuko, 2015-05-08 14:26:01]

On Fri, May 8, 2015 at 11:00 PM, <yurys@chromium.org> wrote:

> On 2015/05/08 13:54:39, kinuko wrote:
>
>> On 2015/05/08 13:35:29, yurys wrote:
>> > On 2015/05/08 12:08:12, kinuko wrote:
>> > > On 2015/05/08 09:27:24, yurys wrote:
>> > > > Why is WorkerScript a more appropriate name than WorkerThread for an
>> object
>> > > that
>> > > > has methods we normally find on threads but no on scripts:
>>
> start/terminate
>
>> > > > execution, post task, enter nested message loop?
>> > >
>> > > WorkerThread no longer really represents a thread as it might be
>> attached
>>
> to
>
>> > > multiple threads and we're afraid that calling it a 'thread' would be
>>
> pretty
>
>> > > confusing.
>> > Does it mean that instance of such class may hop from one worker thread
>> to
>> > another? This would break inspector assumptions that all worker tasks
>> are
>> > executed on one thread. Can you elaborate on this?
>>
>
>  sadrul@ should be able to answer to this.  (In my understanding the
>> instance
>> does not hop from one thread to another (this would not work in current
>>
> blink),
>
>> but one thread may host multiple instances of such class.)
>>
>
> The latter will break worker debugger since we assume that there is one
> worker
> context per isolate on worker thread.
>
> @sadrul: can you shed some light on this?
>
>
>  > > I do think that having methods like 'start/terminate execution',
>> > > 'post task' are totally fine on the new class name (we have similar
>>
> concepts
>
>> > on
>> > > ExecutionContext / GlobalScope etc).
>> > Correct. Moreover, we already have WorkerGlobalScope that implements
>> > ExecutionContext for worker. Unlike WorkerThread it is unclear from the
>> new
>> name
>> > what the responsibilities of WorkerScript compared to e.g.
>> > WorkerScriptController or WorkerGlobalScope are.
>>
>
>  It'd provide 1:1 interface (e.g. start and terminate) to a worker script
>> execution (which hosts a WorkerGlobalScope on a worker thread), and that's
>>
> where
>
>> this name comes from.  We're absolutely open to other suggestions though,
>> I
>> agree that the term 'script' may sound a bit vague in this context.
>>
>
> WorkerThread sounds good enough to me (at least better than WorkerScript
> if we
> leave current interface of the class). It is backed by a platform thread
> but
> that's expected in blink, isn't it?


I still prefer giving this a different name, as far as I know several
people have shown concerns about the possible confusion.  I think the new
name could have 'thread' as a part of it though.  Let me think about this a
bit more (while you and sadrul@ probably need more discussion about the
thread/inspector architecture)

 > > For the methods for entering nested message
>> > > loop I had the same concern (they look a bit misplaced), but what
>> they are
>> > doing
>> > > is not really thread related either.
>> > Normally it is a thread that runs message loop and executes tasks, which
>> > perfectly fits current name of this class. Maybe we should first extract
>>
> such
>
>> > methods into a separate class?
>>
>
>  Yup sounds good.
>>
>
>
> https://codereview.chromium.org/1115923002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[sadrul, 2015-05-11 00:46:52]

On 2015/05/08 14:00:18, yurys wrote:
> On 2015/05/08 13:54:39, kinuko wrote:
> > On 2015/05/08 13:35:29, yurys wrote:
> > > On 2015/05/08 12:08:12, kinuko wrote:
> > > > On 2015/05/08 09:27:24, yurys wrote:
> > > > > Why is WorkerScript a more appropriate name than WorkerThread for an
> > object
> > > > that
> > > > > has methods we normally find on threads but no on scripts:
> start/terminate
> > > > > execution, post task, enter nested message loop?
> > > > 
> > > > WorkerThread no longer really represents a thread as it might be
attached
> to
> > > > multiple threads and we're afraid that calling it a 'thread' would be
> pretty
> > > > confusing.
> > > Does it mean that instance of such class may hop from one worker thread to
> > > another? This would break inspector assumptions that all worker tasks are
> > > executed on one thread. Can you elaborate on this?
> > 
> > sadrul@ should be able to answer to this.  (In my understanding the instance
> > does not hop from one thread to another (this would not work in current
> blink),
> > but one thread may host multiple instances of such class.)
> > 
> The latter will break worker debugger since we assume that there is one worker
> context per isolate on worker thread.
> 
> @sadrul: can you shed some light on this?

Yep. kinuko@ is right. There will be multiple WorkerThread/WorkerScripts active,
each having a separate WorkerGlobalScope/ExecutionContext, but in the same
thread, and the same isolate.

I haven't looked closely at the worker debugger code. Could you clarify a little
what assumptions the debugger code makes? From looking at some inspector/worker
related code, it looks like they deal mostly with the associated
WorkerGlobalScope, and since each WorkerThread/WorkerScript will continue to
have their own WorkerGlobalScope, do you foresee this still breaking other parts
of the code? I have filed http://crbug.com/486574 to track this work.

> 
> 
> > > > I do think that having methods like 'start/terminate execution',
> > > > 'post task' are totally fine on the new class name (we have similar
> concepts
> > > on
> > > > ExecutionContext / GlobalScope etc).
> > > Correct. Moreover, we already have WorkerGlobalScope that implements
> > > ExecutionContext for worker. Unlike WorkerThread it is unclear from the
new
> > name
> > > what the responsibilities of WorkerScript compared to e.g.
> > > WorkerScriptController or WorkerGlobalScope are.
> > 
> > It'd provide 1:1 interface (e.g. start and terminate) to a worker script
> > execution (which hosts a WorkerGlobalScope on a worker thread), and that's
> where
> > this name comes from.  We're absolutely open to other suggestions though, I
> > agree that the term 'script' may sound a bit vague in this context.
> > 
> WorkerThread sounds good enough to me (at least better than WorkerScript if we
> leave current interface of the class). It is backed by a platform thread but
> that's expected in blink, isn't it?
> 
> 
> > > > For the methods for entering nested message
> > > > loop I had the same concern (they look a bit misplaced), but what they
are
> > > doing
> > > > is not really thread related either.
> > > Normally it is a thread that runs message loop and executes tasks, which
> > > perfectly fits current name of this class. Maybe we should first extract
> such
> > > methods into a separate class?
> > 
> > Yup sounds good.

I have sent out https://codereview.chromium.org/1131183003/ to remove the
nested-loop related code from WorkerThread, and filed http://crbug.com/486573 to
farther detach WorkerThread from thread-related tasks.

[sadrul, 2015-05-11 04:44:55]

[snip]

> > > > > For the methods for entering nested message
> > > > > loop I had the same concern (they look a bit misplaced), but what they
> are
> > > > doing
> > > > > is not really thread related either.
> > > > Normally it is a thread that runs message loop and executes tasks, which
> > > > perfectly fits current name of this class. Maybe we should first extract
> > such
> > > > methods into a separate class?
> > > 
> > > Yup sounds good.
> 
> I have sent out https://codereview.chromium.org/1131183003/ to remove the
> nested-loop related code from WorkerThread, and filed http://crbug.com/486573
to
> farther detach WorkerThread from thread-related tasks.

yurys@: just to clarify, with the above changes, do you think the rename to
WorkerScript makes reasonable sense? Or do you still prefer WorkerThread over
it?

[yurys, 2015-05-12 13:19:15]

On 2015/05/11 00:46:52, sadrul wrote:
> On 2015/05/08 14:00:18, yurys wrote:
> > On 2015/05/08 13:54:39, kinuko wrote:
> > > On 2015/05/08 13:35:29, yurys wrote:
> > > > On 2015/05/08 12:08:12, kinuko wrote:
> > > > > On 2015/05/08 09:27:24, yurys wrote:
> > > > > > Why is WorkerScript a more appropriate name than WorkerThread for an
> > > object
> > > > > that
> > > > > > has methods we normally find on threads but no on scripts:
> > start/terminate
> > > > > > execution, post task, enter nested message loop?
> > > > > 
> > > > > WorkerThread no longer really represents a thread as it might be
> attached
> > to
> > > > > multiple threads and we're afraid that calling it a 'thread' would be
> > pretty
> > > > > confusing.
> > > > Does it mean that instance of such class may hop from one worker thread
to
> > > > another? This would break inspector assumptions that all worker tasks
are
> > > > executed on one thread. Can you elaborate on this?
> > > 
> > > sadrul@ should be able to answer to this.  (In my understanding the
instance
> > > does not hop from one thread to another (this would not work in current
> > blink),
> > > but one thread may host multiple instances of such class.)
> > > 
> > The latter will break worker debugger since we assume that there is one
worker
> > context per isolate on worker thread.
> > 
> > @sadrul: can you shed some light on this?
> 
> Yep. kinuko@ is right. There will be multiple WorkerThread/WorkerScripts
active,
> each having a separate WorkerGlobalScope/ExecutionContext, but in the same
> thread, and the same isolate.
> 
> I haven't looked closely at the worker debugger code. Could you clarify a
little
> what assumptions the debugger code makes? From looking at some
inspector/worker
> related code, it looks like they deal mostly with the associated
> WorkerGlobalScope, and since each WorkerThread/WorkerScript will continue to
> have their own WorkerGlobalScope, do you foresee this still breaking other
parts
> of the code? I have filed http://crbug.com/486574 to track this work.
> 
This difference is mostly about of
ScriptDebugServer::getDebugListenerForContext. Compare its implementation for
WorkerScriptDebugServer and PageScriptDebugServer: for the main thread we have
several pages sharing one and the same isolate so we need to map v8::Context to
the page it belongs to; in case of workers we always know that there is exactly
one worker context per isolate and simply return the only listener. If the
latter assumption doesn't hold anymore WorkerScriptDebugServer should be changed
to do correct mapping. Is there a design document or something describing how
workers will share isolate?


> > 
> > 
> > > > > I do think that having methods like 'start/terminate execution',
> > > > > 'post task' are totally fine on the new class name (we have similar
> > concepts
> > > > on
> > > > > ExecutionContext / GlobalScope etc).
> > > > Correct. Moreover, we already have WorkerGlobalScope that implements
> > > > ExecutionContext for worker. Unlike WorkerThread it is unclear from the
> new
> > > name
> > > > what the responsibilities of WorkerScript compared to e.g.
> > > > WorkerScriptController or WorkerGlobalScope are.
> > > 
> > > It'd provide 1:1 interface (e.g. start and terminate) to a worker script
> > > execution (which hosts a WorkerGlobalScope on a worker thread), and that's
> > where
> > > this name comes from.  We're absolutely open to other suggestions though,
I
> > > agree that the term 'script' may sound a bit vague in this context.
> > > 
> > WorkerThread sounds good enough to me (at least better than WorkerScript if
we
> > leave current interface of the class). It is backed by a platform thread but
> > that's expected in blink, isn't it?
> > 
> > 
> > > > > For the methods for entering nested message
> > > > > loop I had the same concern (they look a bit misplaced), but what they
> are
> > > > doing
> > > > > is not really thread related either.
> > > > Normally it is a thread that runs message loop and executes tasks, which
> > > > perfectly fits current name of this class. Maybe we should first extract
> > such
> > > > methods into a separate class?
> > > 
> > > Yup sounds good.
> 
> I have sent out https://codereview.chromium.org/1131183003/ to remove the
> nested-loop related code from WorkerThread, and filed http://crbug.com/486573
to
> farther detach WorkerThread from thread-related tasks.

[yurys, 2015-05-12 13:38:46]

On 2015/05/11 04:44:55, sadrul wrote:
> [snip]
> 
> > > > > > For the methods for entering nested message
> > > > > > loop I had the same concern (they look a bit misplaced), but what
they
> > are
> > > > > doing
> > > > > > is not really thread related either.
> > > > > Normally it is a thread that runs message loop and executes tasks,
which
> > > > > perfectly fits current name of this class. Maybe we should first
extract
> > > such
> > > > > methods into a separate class?
> > > > 
> > > > Yup sounds good.
> > 
> > I have sent out https://codereview.chromium.org/1131183003/ to remove the
> > nested-loop related code from WorkerThread, and filed
http://crbug.com/486573
> to
> > farther detach WorkerThread from thread-related tasks.
> 
> yurys@: just to clarify, with the above changes, do you think the rename to
> WorkerScript makes reasonable sense? Or do you still prefer WorkerThread over
> it?

Yeah, if those issues are addressed renaming this class to WorkerScript would
make sense.

[yurys, 2015-05-12 13:38:57]

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
File Source/core/workers/WorkerScript.h (right):

https://codereview.chromium.org/1115923002/diff/60001/Source/core/workers/Wor...
Source/core/workers/WorkerScript.h:78: // Can be used to wait for this worker
thread to shut down.
The comment should be updated as it refers to "thread".