content: Rename raster threads to worker threads.

content: Rename raster threads to worker threads.

This in preparation for using these threads for more than raster.

BUG=348979
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

[reveman, 2015-06-18 01:20:51]

reveman@chromium.org changed reviewers:
+ avi@chromium.org, enne@chromium.org

[Avi (use Gerrit), 2015-06-18 01:35:38]

"Worker thread" is incredibly generic. I know you're going to do more than
raster on them, but are they still going to be doing graphics work?

Can we have "graphics worker thread" or "graphics thread"?

[reveman, 2015-06-18 03:02:53]

On 2015/06/18 at 01:35:38, avi wrote:
> "Worker thread" is incredibly generic. I know you're going to do more than
raster on them, but are they still going to be doing graphics work?
> 
> Can we have "graphics worker thread" or "graphics thread"?

The use-cases I'm aware of are copying of video frames in media and decoding of
fav-icons but I know that scheduler folks are interested in using this for more.
I'll find out what these additional use-cases are and get back to you.

However, the general idea is that we should not have a different set of worker
threads for each type of tasks but instead one set of worker threads that all
parts of a chrome process can share. This would allow us to better control the
number of threads we use and make it easier to implement more advanced control
such as dynamically adjusting the number of worker threads based on if a process
is doing background work or has visible widgets.

[Avi (use Gerrit), 2015-06-18 03:51:22]

On 2015/06/18 03:02:53, reveman wrote:
> On 2015/06/18 at 01:35:38, avi wrote:
> > "Worker thread" is incredibly generic. I know you're going to do more than
> raster on them, but are they still going to be doing graphics work?
> > 
> > Can we have "graphics worker thread" or "graphics thread"?
> 
> The use-cases I'm aware of are copying of video frames in media and decoding
of
> fav-icons but I know that scheduler folks are interested in using this for
more.
> I'll find out what these additional use-cases are and get back to you.
> 
> However, the general idea is that we should not have a different set of worker
> threads for each type of tasks but instead one set of worker threads that all
> parts of a chrome process can share. This would allow us to better control the
> number of threads we use and make it easier to implement more advanced control
> such as dynamically adjusting the number of worker threads based on if a
process
> is doing background work or has visible widgets.

But don't we already have a thread pool?

[reveman, 2015-06-18 13:34:27]

On 2015/06/18 at 03:51:22, avi wrote:
> On 2015/06/18 03:02:53, reveman wrote:
> > On 2015/06/18 at 01:35:38, avi wrote:
> > > "Worker thread" is incredibly generic. I know you're going to do more than
> > raster on them, but are they still going to be doing graphics work?
> > > 
> > > Can we have "graphics worker thread" or "graphics thread"?
> > 
> > The use-cases I'm aware of are copying of video frames in media and decoding
of
> > fav-icons but I know that scheduler folks are interested in using this for
more.
> > I'll find out what these additional use-cases are and get back to you.
> > 
> > However, the general idea is that we should not have a different set of
worker
> > threads for each type of tasks but instead one set of worker threads that
all
> > parts of a chrome process can share. This would allow us to better control
the
> > number of threads we use and make it easier to implement more advanced
control
> > such as dynamically adjusting the number of worker threads based on if a
process
> > is doing background work or has visible widgets.
> 
> But don't we already have a thread pool?

We have base::WorkerPool but it doesn't provide the task dependencies and
ability to cancel and re-prioritize tasks that is required by the raster system.
It would be nice to just have one thread pool eventually. It should be possible
to implement base::WorkerPool on top of the more advanced TaskGraphRunner
interface used by what we currently call "raster"-threads.

[Avi (use Gerrit), 2015-06-18 14:28:16]

On 2015/06/18 13:34:27, reveman wrote:
> On 2015/06/18 at 03:51:22, avi wrote:
> > On 2015/06/18 03:02:53, reveman wrote:
> > > On 2015/06/18 at 01:35:38, avi wrote:
> > > > "Worker thread" is incredibly generic. I know you're going to do more
than
> > > raster on them, but are they still going to be doing graphics work?
> > > > 
> > > > Can we have "graphics worker thread" or "graphics thread"?
> > > 
> > > The use-cases I'm aware of are copying of video frames in media and
decoding
> of
> > > fav-icons but I know that scheduler folks are interested in using this for
> more.
> > > I'll find out what these additional use-cases are and get back to you.
> > > 
> > > However, the general idea is that we should not have a different set of
> worker
> > > threads for each type of tasks but instead one set of worker threads that
> all
> > > parts of a chrome process can share. This would allow us to better control
> the
> > > number of threads we use and make it easier to implement more advanced
> control
> > > such as dynamically adjusting the number of worker threads based on if a
> process
> > > is doing background work or has visible widgets.
> > 
> > But don't we already have a thread pool?
> 
> We have base::WorkerPool but it doesn't provide the task dependencies and
> ability to cancel and re-prioritize tasks that is required by the raster
system.
> It would be nice to just have one thread pool eventually. It should be
possible
> to implement base::WorkerPool on top of the more advanced TaskGraphRunner
> interface used by what we currently call "raster"-threads.

OK, but we can't have "worker threads" and "base::WorkerPool" and not expect
confusion. Until we do that unification, we need some kind of name
differentiation.

[reveman, 2015-06-18 14:48:47]

On 2015/06/18 at 14:28:16, avi wrote:
> On 2015/06/18 13:34:27, reveman wrote:
> > On 2015/06/18 at 03:51:22, avi wrote:
> > > On 2015/06/18 03:02:53, reveman wrote:
> > > > On 2015/06/18 at 01:35:38, avi wrote:
> > > > > "Worker thread" is incredibly generic. I know you're going to do more
than
> > > > raster on them, but are they still going to be doing graphics work?
> > > > > 
> > > > > Can we have "graphics worker thread" or "graphics thread"?
> > > > 
> > > > The use-cases I'm aware of are copying of video frames in media and
decoding
> > of
> > > > fav-icons but I know that scheduler folks are interested in using this
for
> > more.
> > > > I'll find out what these additional use-cases are and get back to you.
> > > > 
> > > > However, the general idea is that we should not have a different set of
> > worker
> > > > threads for each type of tasks but instead one set of worker threads
that
> > all
> > > > parts of a chrome process can share. This would allow us to better
control
> > the
> > > > number of threads we use and make it easier to implement more advanced
> > control
> > > > such as dynamically adjusting the number of worker threads based on if a
> > process
> > > > is doing background work or has visible widgets.
> > > 
> > > But don't we already have a thread pool?
> > 
> > We have base::WorkerPool but it doesn't provide the task dependencies and
> > ability to cancel and re-prioritize tasks that is required by the raster
system.
> > It would be nice to just have one thread pool eventually. It should be
possible
> > to implement base::WorkerPool on top of the more advanced TaskGraphRunner
> > interface used by what we currently call "raster"-threads.
> 
> OK, but we can't have "worker threads" and "base::WorkerPool" and not expect
confusion. Until we do that unification, we need some kind of name
differentiation.

Makes sense. Ignore this patch for now. We'll just use "raster" for lack of
better name until we've been able to unify all worker threads.

[Avi (use Gerrit), 2015-06-18 14:51:10]

On 2015/06/18 14:48:47, reveman wrote:
> On 2015/06/18 at 14:28:16, avi wrote:
> > On 2015/06/18 13:34:27, reveman wrote:
> > > On 2015/06/18 at 03:51:22, avi wrote:
> > > > On 2015/06/18 03:02:53, reveman wrote:
> > > > > On 2015/06/18 at 01:35:38, avi wrote:
> > > > > > "Worker thread" is incredibly generic. I know you're going to do
more
> than
> > > > > raster on them, but are they still going to be doing graphics work?
> > > > > > 
> > > > > > Can we have "graphics worker thread" or "graphics thread"?
> > > > > 
> > > > > The use-cases I'm aware of are copying of video frames in media and
> decoding
> > > of
> > > > > fav-icons but I know that scheduler folks are interested in using this
> for
> > > more.
> > > > > I'll find out what these additional use-cases are and get back to you.
> > > > > 
> > > > > However, the general idea is that we should not have a different set
of
> > > worker
> > > > > threads for each type of tasks but instead one set of worker threads
> that
> > > all
> > > > > parts of a chrome process can share. This would allow us to better
> control
> > > the
> > > > > number of threads we use and make it easier to implement more advanced
> > > control
> > > > > such as dynamically adjusting the number of worker threads based on if
a
> > > process
> > > > > is doing background work or has visible widgets.
> > > > 
> > > > But don't we already have a thread pool?
> > > 
> > > We have base::WorkerPool but it doesn't provide the task dependencies and
> > > ability to cancel and re-prioritize tasks that is required by the raster
> system.
> > > It would be nice to just have one thread pool eventually. It should be
> possible
> > > to implement base::WorkerPool on top of the more advanced TaskGraphRunner
> > > interface used by what we currently call "raster"-threads.
> > 
> > OK, but we can't have "worker threads" and "base::WorkerPool" and not expect
> confusion. Until we do that unification, we need some kind of name
> differentiation.
> 
> Makes sense. Ignore this patch for now. We'll just use "raster" for lack of
> better name until we've been able to unify all worker threads.

If you want, you can add some kind of note to the class comment, saying that the
threads are used for more than just rasterizing.