This is a no-op migration from base::ThreadPriority to base::ThreadType.
Except for the name changes of enum classes and functions, their
behavior should be kept unchanged. By using the new ThreadType API, the
caller declare the type of work a thread runs, and let the platform
implementation decide its behavior. Apart from the current priority
setting, the QoS API will further be used on some platforms.
Mappings in existing callers are as follows:
ThreadPriority::BACKGROUND => ThreadType::kBackground
ThreadPriority::NORMAL => ThreadType::kDefault
ThreadPriority::DISPLAY for compositing only on select
platforms (WIN, ANDROID, CrOS)
=> ThreadType::kCompositing
ThreadPriority::DISPLAY unconditionally on *all* platforms
=> ThreadType::kDisplayCritical
ThreadPriority::REALTIME_AUDIO => ThreadType::kRealtimeAudio
As this CL aims to make all platform-specific decisions in the
platform_thread_<platform>.cc impls, ifdef exceptions on main threads
(like on Mac) have moved to their respective impls.
The resulting callers should thus have no ifdefs left except for the odd
exception with a TODO we aim to unravel after this no-op CL.
ifdefs for render_message_filter()->SetThreadType() stay for now as this
call is already platform specific.
Bug: 1278628, 1324809
Change-Id: I36fbc4fc988c12e712da2e131595255a7b4fe4b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3329026
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Zhibo Wang <zhibo1.wang@intel.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Olga Sharonova <olka@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Peng Huang <penghuang@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Markus Handell <handellm@google.com>
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1021517}
This patch creates ThreadPool earlier, so that it's guaranteed to exist
before creating field trials. Now both field trials and the ThreadPool
always exist in PostFieldTrialInitialization.
A followup patch will use this entry point to start the heap profiler
in child processes.
Bug: 1327069
Change-Id: I2258fb77f06557460e342144e1c76de13985a4c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3654912
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1010574}
The original change to use ThreadPriority::DISPLAY for the renderer
compositor thread (7b97c3240f "base: Allow renderer thread priorities
to be changed.") also applied the priority to the IO thread to avoid
delays in IPC message delivery to the compositor thread.
We recently added a feature to control compositor thread priority, but it
does not affect setting the IO thread priority. Instead, we always try to
raise the priority on Linux, Android, & Chrome OS, and never try on
Windows or Mac. This causes strange situations such as having render
IO threads run with higher priority than any browser or GPU process
thread even though the priority Features were disabled.
Fix the BlinkCompositorUseDisplayThreadPriority feature to also apply to
the IO thread and use it to control the initial thread priority, as well
as whether we ask the browser to adjust it (which is used on Chrome OS
for some cgroup manipulation that needs to be done from the browser).
After this change, each of the display priority flags also control the IO
thread priority of the corresponding process.
Bug: 937462
Change-Id: I1950182fccd8bc6ea35359792878283c2fd9401c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1714204
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681121}
In order to leave the base::ThreadPool symbol available for
an upcoming "destination" task trait.
Also moved ThreadPoolImpl to be the implementation of TaskExecutor,
not ThreadPoolInstance. It was a mistake that base::ThreadPool was
implementing TaskExecutor, its users shouldn't have access to
PostTask*() and Create*TaskRunner*().
TBR=fdoray@chromium.org
(bypass owners for side-effects beyond //base)
Bug: 968047
Change-Id: I0607fba6d7f30d202bf7f61a9f461b1256e87467
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1634851
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#664300}
Reason: with the advent of other scheduling primitives in //base
(i.e. SequenceManager), TaskScheduler was no longer the only component
responsible for scheduling tasks. We will from now on refer to the
whole of //base/task as the "task scheduling infrastructure".
There are other types named "TaskScheduler" outside of base:: so
s/TaskScheduler/ThreadPool/ across the codebase wasn't possible.
Instead, this CL did:
1) base/task/task_scheduler => base/task/thread_pool
(catches all files with includes)
1.1) Careful manual search to add files without includes
(e.g. missing IWYU, docs, etc.)
2) TaskScheduler => ThreadPool in all files affected by (1)
3) task_scheduler => thread_pool in all files affected by (1)
4) "task scheduler" => "thread pool" in all files affected by (1)
4) Move task_scheduler_util like headers in
//content //components and //ios
Also:
* Renamed UMA metrics from TaskScheduler.* to ThreadPool.*
and dropped "Pool" from worker pool name suffixes.
* Renamed TaskScheduler*Worker thread names to ThreadPool*Worker
* In base/android: NativeTaskScheduler => NativeScheduler as it
was referring to the whole of base/task.
TaskSchedulerTest.java => NativePostTaskTest.java (former DNE)
* Intentionally ignoring IWYU violations in this already too large
CL.
In follow-up:
* Rename other types as well:
SchedulerWorker => WorkerThread
SchedulerWorkerPool* => WorkerThreadGroup*
Bug: 951388
Change-Id: I5bc2688b593c7682ef7e56d6b228539970ba107e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1561552
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#650997}
Initialization with an arbitrary vector of SchedulerWorkerPoolParams
is being deprecated.
BUG=690706
Review-Url: https://codereview.chromium.org/2798623002
Cr-Commit-Position: refs/heads/master@{#461828}
Previously, the constructor of ChildProcess called
ChildProcess::InitializeTaskScheduler() to initialize TaskScheduler.
RenderProcessImpl overrode this method to initialize TaskScheduler
with custom arguments. Unfortunately, the constructor of a base
class cannot call methods from a derived class.
This CL removes the virtual ChildProcess::InitializeTaskScheduler()
method. RnederProcessImpl passes its custom TaskScheduler
initialization arguments to the constructor of ChildProcess.
BUG=664996
Review-Url: https://codereview.chromium.org/2687903003
Cr-Commit-Position: refs/heads/master@{#449785}
