This is taking care of a long-standing TODO to move these OnceClosure
holders rather than copy them around with their OnceClosure* members.
This is a precursor to
https://chromium-review.googlesource.com/c/chromium/src/+/3187153/35#message-fcc92e9f85e73f0e5ba6c03610a95cda8736f1f9
which highlighted a problem where some tests see a non-null
MainFunctionParams::ui_task but running the closure results in a UAF.
Logs show that the test hitting the UAF is not the one setting this
field. This CL makes that impossible and fixes the issue in the
follow-up CL.
This CL is intended to be a logical no-op.
This CL touches a lot of files and must happen all at once.
The core change is that ContentMainParams and MainFunctionParams's
moveable fields (ui_task, created_main_parts_closure, and startup_data)
are now held by moveable types rather than raw pointers.
This trickles in the following chain:
main() (in various *_main.cc)
(or SetUp() in !OS_ANDROID browser_test_base.cc)
-> ContentMain()
-> ContentMainRunnerImpl::Initialize()
(forwards arg into MainFunctionParams)
-> RunBrowser()
-> BrowserMain()
-> BrowserMainRunnerImpl::Initialize()
-> BrowserMainLoop (stores MainFunctionParams)
-> BrowserMainLoop::Init
-> ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)ContentBrowserClient::CreateBrowserMainParts()
-> (Embedder)BrowserMainParts(Platform)
-> (Embedder)BrowserMainParts
-> RunOtherNamedProcessTypeMain()
-> (Embedder)ContentMainDelegate::RunProcess()
(or)
-> FooMain() (kMainFunctions)
(or)
-> RunZygote()
(creates its own MainFunctionParams)
-> (Embedder)ContentMainDelegate::RunProcess()
(on OS_ANDROID, browser_test_base.cc calls directly into
ContentMainDelegate::RunProcess())
Few of these needed the params after passing them down so a move-only
model was simple to adapt (even if invasive). The few exceptions like
BrowserMainRunnerImpl::Initialize consuming |created_main_parts_closure|
are better off in the new model (where they take the OnceClosure before
passing down the params) because that prevents others down the chain
from having access to a OnceClosure they shouldn't invoke anyways.
Noteworthy:
- ContentMainDelegate::RunProcess():
Returned an exit_code >= 0 to indicate the embedder elected to handle
the run request given these params. With move-only semantics it is
necessary to return the params back when the embedder declines
handling this run request. An absl::variant return value is used
to satisfy this requirement.
- content/public/test/test_launcher.h : GetContentMainParams():
Becomes CopyContentMainParams() and only exposes a copy of copyable
params. Uses new ContentMainParams::ShallowCopyForTesting() which
verifies that moveable fields are still null by that time as should be
the case in the order browser tests are initialized.
- MainFunctionParams::command_line being const& violated the style-guide
rule to "avoid defining functions that require a const reference
parameter to outlive the call". This also prevented moving. The type
was hence switched to a const CommandLine*.
- BUILD.gn changes for nacl_helper_win_64 which requires static linking
of its minimal //content deps (was previously missing a dep but was
getting away with it because MainFunctionParams was .h only; required
now with .cc). This was already done for static_switches and this CL
adds static_main_function_params, reusing a similar static_features
target that already existed but was no longer required in
/c/nacl/broker, cleaning that up by replacing rather than copying that
target's definition in this CL.
- ContentMainParams::minimal_browser_mode was weirdly passed as a
parameter to ContentMainRunner::Run(bool start_minimal_browser) but
that method also has access to the ContentMainParams originally passed
via ContentMainRunner::Init(). Passing the param again from Run()
would be a use-after-move in content_main.cc, instead
content_main_runner_impl.cc was updated to use the param it already
has in store.
Bug: 1175074
Change-Id: I3af90505525e426383c59107a3903d645d455682
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244976
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Owners-Override: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940478}
@QA: This CL is a no-op.
The meaning of this phase has diverged and become increasingly
confusing over the years.
This is not the timing at which the main message loop starts but rather
this is where it is created.
The previous term is easily confused with things like
VariationsService::PerformPreMainMessageLoopStartup
startup_metric_utils::RecordBrowserMainMessageLoopStart
that actually represent when the message loop starts.
This confusion has led to new calls being associated with the wrong
phase, e.g.
https://chromium-review.googlesource.com/c/chromium/src/+/2685139/6#message-d1f863178a7982698d1ff5a032b79e33e9e1d5ce
Bug: 1175074
Change-Id: I0535042abe69431501c9b3da3cfb2eae445fde0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2892278
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Owners-Override: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#883468}
Refactor BrowserMainParts so that BrowserMainLoop owns the loop and
only gives embedders the opportunity to configure it before it runs it.
This is intended to be a no-op logic wise but will be key in a follow-up
change where the loop will be run in multiple steps (until "first idle"
and then forever with a new BrowserMainParts::OnFirstIdle() phase in
between):
https://chromium-review.googlesource.com/c/chromium/src/+/2678899
It was previously strange to have all phases managed by BrowserMainLoop
(BrowserMainParts is only for Pre/Post); *except* for actually running
the loop.
The key changes are in browser_main_loop.cc and in browser_main_parts.h
where this CL introduces WillRunMainMessageLoop() as a replacement for
an overridable MainMessageLoopRun(). Everything else is a side-effect of
that change (intended to be a no-op).
WillRunMainMessageLoop() was necessary instead of augmenting
PreMainMessageLoopRun() because the latter is part of
CreateStartupTasks() and unintuitively runs in a separate phase of
startup which is not guaranteed to be immediately before
MainMessageLoopRun()...
PreMainMessageLoopRun() was modified slightly to return the |error_code|
like many of its sibling methods already did (this was previously an
out-param on MainMessageLoopRun() but no overrides modified the value
after PreMainMessageLoopRun()).
Also took advantage of this CL to further document each phase's role.
Bug: 1175074
Change-Id: I44f84781340fe15efdeac73c7ac35367b1c216f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2725153
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#863314}
Note to QA: This CL is purely mechanical and shouldn't be blamed
for future regressions on touched files.
This is a follow-up to https://chromium-review.googlesource.com/c/chromium/src/+/2211138
which already removed all usage using content::BrowserThread.
Hence this script now matches unqualified BrowserThread:: without
risking having "content::" be selected as "traits_before" by the regex
(ran on same revision as step #1).
content:: is now always added if outside namespace content {}
(deleting unused using content::BrowserThread; decls)
Script @ https://crbug.com/1026641#c92
(will TBR fdoray@ post-review for mechanical change)
TBR=fdoray@hchromium.org
AX-Relnotes: n/a.
Bug: 1026641
Change-Id: I51ae2f83eb17d19b54563fd9b4fc040d2aa0c948
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2212469
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#772458}
This introduces a new MojoDedicatedThread feature to Content which, when
enabled, changes Mojo to use a dedicated background thread for receiving
incoming IPCs rather than using Content's IO thread.
The feature is disabled by default.
Bug: 1082761
Change-Id: Ia68f288309a316be14b5254e9c4f006b6f8c74cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2202143
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#768903}
This CL is a logical no-op.
It manually covers the use cases the script
(https://crbug.com/1026641#c22) didn't cover in
https://chromium-review.googlesource.com/c/chromium/src/+/2026350.
A few of the affected files were also migrated to
content::GetUIThreadTaskRunner() whenever surrounding code consistency
was at stake (but the bulk of that migration is staged to happen after
this one so this wasn't a priority in this batch).
Most files intentionally kept base/task/post_task.h as an include. It is
still required because of a cyclical dependency during the migration
preventing base/task/thread_pool.h from implicitly providing
base/task/task_traits.h to its users (callers that explicitly store
TaskTraits and include task_traits.h don't have this problem). The
post_task.h include will be cleaned up in a later phase.
This CL was uploaded by git cl split.
R=boliu@chromium.org
Bug: 1026641
Change-Id: I165a26f5d13f84d1f7ef03228e5faa34fe7c9a86
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2078660
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#745484}
Basically ran
sed -i '/base\/message_loop\/message_loop.h/d'
for a bunch of files that no longer use MessageLoop. Came up with the
file list by a combination of greps and trial and error compiles. It is
still possible, but unlikely, that I had false positives but due to
transitive dependencies the compiles succeed. Given that we will
eventually get rid of message_loop.h entirely this should be fine.
If any of the optional try jobs fails to build please consider just
adding #include "base/message_loop/message_loop.h"
to the files that fail to build instead of reverting the entire patch.
This patch will be reviewed according to
https: //chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#mechanical-changes
TBR=gab@chromium.org
Bug: 891670
Change-Id: If56ad40631b3ce02931149cb754131c6a021d899
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1829080
Reviewed-by: Carlos Caballero <carlscab@google.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Carlos Caballero <carlscab@google.com>
Cr-Commit-Position: refs/heads/master@{#708563}
*** Note: There is no behavior change from this patch. ***
The PostTask APIs will shortly be changed to require all tasks to explicitly
specify their thread affinity, i.e., whether the task should run on the thread
pool or a specific named thread such as a BrowserThread. This patch updates all
call sites with thread affinity annotation. We also remove the "WithTraits"
suffix to make the call sites more readable.
Before:
// Thread pool task.
base::PostTaskWithTraits(FROM_HERE, {...}, ...);
// UI thread task.
base::PostTaskWithTraits(FROM_HERE, {BrowserThread::UI, ...}, ...);
After:
// Thread pool task.
base::PostTask(FROM_HERE, {base::ThreadPool(), ...}, ...);
// UI thread task.
base::PostTask(FROM_HERE, {BrowserThread::UI, ...}, ...);
This patch was semi-automatically prepared with these steps:
1. Patch in https://chromium-review.googlesource.com/c/chromium/src/+/1635827
to make thread affinity a build-time requirement.
2. Run an initial pass with a clang rewriter:
https://chromium-review.googlesource.com/c/chromium/src/+/1635623
3. ninja -C out/Debug | grep 'requested here' | cut -d: -f1-3 | sort | \
uniq > errors.txt
4. while read line; do
f=$(echo $line | cut -d: -f 1)
r=$(echo $line | cut -d: -f 2)
c=$(echo $line | cut -d: -f 3)
sed -i "${r}s/./&base::ThreadPool(),/$c" $f
done < errors.txt
5. GOTO 3 until build succeeds.
6. Remove the "WithTraits" suffix from task API call sites:
$ tools/git/mffr.py -i <(cat <<EOF
[
["PostTaskWithTraits", "PostTask"],
["PostDelayedTaskWithTraits", "PostDelayedTask"],
["PostTaskWithTraitsAndReply", "PostTaskAndReply"],
["CreateTaskRunnerWithTraits", "CreateTaskRunner"],
["CreateSequencedTaskRunnerWithTraits", "CreateSequencedTaskRunner"],
["CreateUpdateableSequencedTaskRunnerWithTraits", "CreateUpdateableSequencedTaskRunner"],
["CreateSingleThreadTaskRunnerWithTraits", "CreateSingleThreadTaskRunner"],
["CreateCOMSTATaskRunnerWithTraits", "CreateCOMSTATaskRunner"]
]
EOF
)
This CL was uploaded by git cl split.
R=boliu@chromium.org, tsepez@chromium.org
Bug: 968047
Change-Id: I346372d16a3856186ea74d14e0dd8a12f7cacae5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1729589
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#683554}
This ensures the Service Manager is always initialized by
ContentMainRunnerImpl early in process startup, rather than potentially
deferring until BrowserMainLoop runs. The main motivation here is to
have only one place in browser code where the Service Manager is
initialized.
This also begins peeling away at some of the unnecessary dependencies on
ServiceManagerConnection and ServiceManagerContext, since both are slated
for deletion.
Finally, this adds a public content::GetSystemConnector API to
content/public/browser as a drop-in replacement for
ServiceManagerConnection::GetForProcess()->GetConnector(). Moving
forward, this is the API that new browser code should use when
connecting to services. The API is available very early in browser
startup, even before BrowserMainLoop is instantiated.
Bug: 904240, 968147
Change-Id: I933dc8a4bf268cec92eaa4cbdc452c1fc2a08898
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1650155
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Xi Han <hanxi@chromium.org>
Reviewed-by: Olga Sharonova <olka@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#668977}
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}
This reverts commit f481306ad9 and
disables following tests on Windows:
* RenderThreadImplBrowserTest.NonResourceDispatchIPCTasksDontGoThroughScheduler
* UserScriptListenerTest.NavigationWaitsForContentScriptsToLoad
Reason for revert: Causes BrowserMainLoopTest, CreateThreadsInSingleProcess to fail every time content_unittests is run, if DCHECKs are enabled.
Original change's description:
> Reland "Start ServiceManger before creating BrowserMainLoop."
>
> This relands commit aa60c21940. The original CL
> (https://crrev.com/c/1113802) got reverted becuase FeatureList and field
> trials are not setup properly in early startup in Android WebView, but
> ServiceMangerContext has checked features. See crbug.com/899376. The fix is
> in a separate CL: https://crrev.com/c/1305876. Another related precursor CL
> is: https://crrev.com/c/1308096.
>
> This CL is an exact copy of the original CL.
>
> The original cl description is:
> This CL instantiates the ServiceManagerContext before creating
> the BrowserMainRunner. It splits the startup path into two,
> with/without starting the full browser. The changes are implemented
> behind a flag "allow-start-service-manager-only".
>
> Bug: 846846,729596
> TBR: jam@chromium.org
> Change-Id: I5214af850d4ef256c9d223db059ed009a42de714
> Reviewed-on: https://chromium-review.googlesource.com/c/1305822
> Commit-Queue: Xi Han <hanxi@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#604969}
TBR=gab@chromium.org,jam@chromium.org,hanxi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 846846, 729596, 902311
Change-Id: I8b46711602a240023f4a03a69aa70f66d4eee726
Reviewed-on: https://chromium-review.googlesource.com/c/1322343
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606004}
This relands commit aa60c21940. The original CL
(https://crrev.com/c/1113802) got reverted becuase FeatureList and field
trials are not setup properly in early startup in Android WebView, but
ServiceMangerContext has checked features. See crbug.com/899376. The fix is
in a separate CL: https://crrev.com/c/1305876. Another related precursor CL
is: https://crrev.com/c/1308096.
This CL is an exact copy of the original CL.
The original cl description is:
This CL instantiates the ServiceManagerContext before creating
the BrowserMainRunner. It splits the startup path into two,
with/without starting the full browser. The changes are implemented
behind a flag "allow-start-service-manager-only".
Bug: 846846,729596
TBR: jam@chromium.org
Change-Id: I5214af850d4ef256c9d223db059ed009a42de714
Reviewed-on: https://chromium-review.googlesource.com/c/1305822
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604969}
As a final step, replace all includes back:
- mv message_loop_current.h message_loop.h
- s/message_loop_forward.h/message_loop.h/ in all includes.
- s/message_loop_forward.h/message_loop.h/ in base/BUILD.gn
- Remove message_loop_forward.h from third_party/DEPS.
TBR=gab@chromium.orgR=gab@chromium.org
BUG=891670
Change-Id: I623077025701459ddb7045cbcfdad138aa90a9e4
Reviewed-on: https://chromium-review.googlesource.com/c/1313110
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604690}
To facilitate splitting MessageLoop into MessageLoop and MessageLoopImpl
introduce message_loop_forward.h and use it everywhere.
- s/message_loop.h/message_loop_forward.h/ in all includes.
- Add message_loop_forward.h to base/BUILD.gn.
- Add message_loop_forward.h to third_party/DEPS.
TBR=gab@chromium.org
BUG=891670
Change-Id: Ibac3a24f5bd4291c9d57dd32c627477e4e6ef324
Reviewed-on: https://chromium-review.googlesource.com/c/1313108
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604672}
This reverts commit aa60c21940.
Reason for revert: it breaks network_service_webview_instrumentation_test_apk on Mojo Android Build:
https://bugs.chromium.org/p/chromium/issues/detail?id=899376
Bug:899376
Original change's description:
> Start ServiceManger before creating BrowserMainLoop.
>
> This CL instantiates the ServiceManagerContext before creating
> the BrowserMainRunner. It splits the startup path into two,
> with/without starting the full browser. The changes are implemented
> behind a flag "allow-start-service-manager-only".
>
> Bug: 846846,729596
> Change-Id: I3584db0d89a10e59d6041e0f4412aaffdc840568
> Reviewed-on: https://chromium-review.googlesource.com/c/1113802
> Commit-Queue: Xi Han <hanxi@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#603092}
TBR=gab@chromium.org,jam@chromium.org,hanxi@chromium.org
Change-Id: I866cc2148d529d0d7a02d0ac75b2817d1695a8c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 846846, 729596
Reviewed-on: https://chromium-review.googlesource.com/c/1303042
Reviewed-by: Xi Han <hanxi@chromium.org>
Commit-Queue: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603194}
This CL instantiates the ServiceManagerContext before creating
the BrowserMainRunner. It splits the startup path into two,
with/without starting the full browser. The changes are implemented
behind a flag "allow-start-service-manager-only".
Bug: 846846,729596
Change-Id: I3584db0d89a10e59d6041e0f4412aaffdc840568
Reviewed-on: https://chromium-review.googlesource.com/c/1113802
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603092}
This is a follow up CL for: https://crrev.com/c/1115783.
In this CL, we use ScopedExecutionFence to prevents tasks running between the
peorid from BrowserMainRunner is instantiated to
BrowserMainLoop::CreateThreads() is called.
Bug: 846846
Change-Id: I9dec8415e45f901c5883c196ab867c0ea4928594
Reviewed-on: https://chromium-review.googlesource.com/c/1174955
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597255}
The call to BrowserTaskExecutor::ResetForTesting() happens too early:
ShutdownThreadsAndCleanUp will require it to be present once we replace
BrowserThread::PostTask with base::PostTaskWithTraits.
Bug: 878356
Change-Id: I7b2913288705107b509655c0a0cdb43374eb0157
Reviewed-on: https://chromium-review.googlesource.com/1227993
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Alex Clarke <alexclarke@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591822}
This adds TestBrowserThreadBundles to unittests that will need it when
we replace BrowserThread::PostTask() and friends with base/post_task.h.
The TestBrowserThreadBundle initializes globals that are required for
things like posting a task to or obtaining a TaskRunner for a BrowserThread.
I'm making this change in a separate patch to make review of the
future automated refactoring patches easier.
Bug: 878356
Change-Id: I100eefb16afa5490c9c7dee56c9a0bdb72501524
Reviewed-on: https://chromium-review.googlesource.com/1208170
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590387}
When this CL is approved I will rebase it on top of tree and mass
migrate all callers in a new patch set (TBR'ed change).
TBR=robliao@chromium.org (for mass migration of existing callers)
Bug: 867421
Change-Id: I41092bbc4824964ee047e0bf53e972c8f6e896a4
Reviewed-on: https://chromium-review.googlesource.com/1161116
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580845}
Core move CL : https://chromium-review.googlesource.com/c/chromium/src/+/1161088
Move strategy :
1) Rebase this CL on ToT and mass migrate all callers of public base/task_scheduler
headers to their matching *_forward.h header.
2) Land core move CL
3) Mass migrate away from *_forward.h headers in
https://chromium-review.googlesource.com/c/chromium/src/+/1161116
This move strategy was chosen to keep as much git history as possible
in (2). See code comments on forward headers for details.
Once this CL and its follow-ups are approved, I will sync it to
top-of-tree, mass migrate all existing users of these headers to
their *_forward.h version in this CL (TBR'ed) and follow-up with
the other two swiftly back-to-back.
TBR=robliao@chromium.org (for mass migration of existing callers)
Bug: 867421
Change-Id: Iea684e022181c0611abe7f92629599afc369822b
Reviewed-on: https://chromium-review.googlesource.com/1161179
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580622}
The service manager thread and (TODO) ServiceManager might be created
before the full browser starts, and we want to reuse them when starting
the full browser. Therefore, we add a pointer of BrowserStartupData in
MainFunctionParams.
Particularly, in this CL, ContentMainRunnerImpl creates and owns a
BrowserStartupData object. It passes a pointer of the BrowserStartupData
through the main function parameter to BrowserMainLoop.
The BrowserStartupData interface was introduced in:
https://crrev.com/c/1117471.
Bug: 846846, 853308
Change-Id: Ie11063227a670cd8d72935131e854ee2b5c46e4e
Reviewed-on: https://chromium-review.googlesource.com/1108178
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574054}
When ServiceManager starts, it needs to post sequence tasks.
Therefore, we need to create a TaskScheduler and setup the
MessageLoop for the main thread.
Pariculaly for mac, the Mac registaration of NSApp now happens before
EarlyInitialization. The registration has been moved from
BrowserMainParts::PreMainMessageLoopStart() to ContentMainDelegate's
subclasses which implement ContentMainDelegate::PreMainMessageLoopStart().
This is required by a follow up CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1058131/
Change-Id: Ic67dace05b82fc44d6ab6d480ba0fecffe58fbf8
Reviewed-on: https://chromium-review.googlesource.com/1072387
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567244}
This is a reland of I23ef57eb52bfb1eb363682dadf98c571c12afcd1.
It was reverted in Ia548067acbf640010f4c8fbed29a0012a274af05. Reason for revert:
Findit (https://goo.gl/kROfz5) identified this CL at revision 557680 as the culprit
for introducing flakiness in the tests as shown on:
https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vZmM5NTUwMWZiMjllM2U3NDg3ZmZmOThjMTdlNmFhYmExMDQ2YjMzMAw
The data race has been fixed in:
https://chromium-review.googlesource.com/c/chromium/src/+/1064450.
Original change's description:
> Create BrowserThread::IO thread before browser main loop to start
> ServiceManager.
>
> We need a thread to post/execute tasks when starting the
> ServiceManager. This thread needs to be created before the browser
> main loop is initialized, and will be registered as the
> BrowserThread::IO thread which is currently used by ServiceManager
> connections.
>
> The creation of such a thread is moved to service_manager::main via
> MainDelegate::CreateIOThreadAndGetTaskRunner(). Since it requires no
> thread created before calling fork() on posix, we also move the setup
> of sandbox before creating the IO thread.
>
> Bug: 740677, 729596
> Change-Id: I23ef57eb52bfb1eb363682dadf98c571c12afcd1
> Reviewed-on: https://chromium-review.googlesource.com/969098
> Commit-Queue: Xi Han <hanxi@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#557680}
Bug: 740677, 729596
Change-Id: I9afb0cdc0f11a1d437c2e9bd09c374503c3d5a4b
Reviewed-on: https://chromium-review.googlesource.com/1059949
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560724}
ServiceManager.
We need a thread to post/execute tasks when starting the
ServiceManager. This thread needs to be created before the browser
main loop is initialized, and will be registered as the
BrowserThread::IO thread which is currently used by ServiceManager
connections.
The creation of such a thread is moved to service_manager::main via
MainDelegate::CreateIOThreadAndGetTaskRunner(). Since it requires no
thread created before calling fork() on posix, we also move the setup
of sandbox before creating the IO thread.
Bug: 740677, 729596
Change-Id: I23ef57eb52bfb1eb363682dadf98c571c12afcd1
Reviewed-on: https://chromium-review.googlesource.com/969098
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557680}
This is a reland of d260e9cf66
It was reverted because of crbug.com/824716, these weren't new crashes
but known crashes mislabeled as a fallout of this change.
http://cl/190471699 fixes the crash backend to not rely on
"content::BrowserThreadImpl::IOThreadRun" being in the signature.
Only diff in this CL is to use base::debug::Alias() in methods that we
don't want optimized (i.e. IOThreadRun) out as CHECK_GT was seen as
optimized out in some of the reported crashes (even though the same
pattern as before was used by this CL..?)
Original change's description:
> Refactor BrowserThreadImpl, BrowserProcessSubThread, and BrowserMainLoop
>
> This brings back the invariant that BrowserThread::IO isn't available
> before BrowserMainLoop::CreateThreads(). This was broken to fix issue
> 729596 to bring up the thread earlier for ServiceManager but it is
> important that code that posts to BrowserThread::IO statically have an
> happens-after relationship to BrowserMainLoop::CreateThreads(). Exposing
> it statically earlier put that invariant at risk.
>
> Thankfully fixing issue 815225 resulted in finally reaching the long
> sought goal of only having BrowserThread::UI/IO. Now that the IO thread
> is also kicked off before it's named statically, BrowserThreadImpl no
> longer needs to be a base::Thread, hence this refactoring.
>
> Before this CL:
> * BrowserThreadImpl was a base::Thread
> (could be a fake thread if SetMessageLoop was used)
> * BrowserProcessSubThread was a BrowserThreadImpl
> (performed a bit more initialization)
> * BrowserProcessSubThread was only used in production (in
> BrowserMainLoop)
> * BrowserThreadImpl was used for fake threads (BrowserMainLoop for
> BrowserThread::UI) and for testing (TestBrowserThread(Impl)).
> * BrowserThreadImpl overrode Init/Run/CleanUp() from base::Thread to
> perform some sanity checks as well as drive IOThread's Delegate (ref.
> BrowserThread::SetIOThreadDelegate())
> * BrowserProcessSubThread re-overrode Init/Run/CleanUp() to perform
> per-thread //content initialization (tests missed out on that per
> TestBrowserThread bypassing BrowserProcessSubThread by directly
> subclassing BrowserThreadImpl).
>
> With this CL:
> * BrowserThreadImpl is merely a scoped object that binds a provided
> SingleThreadTaskRunner to a BrowserThread::ID.
> * BrowserProcessSubThread is a base::Thread and performs all of the
> initialization and cleanup specific to //content (this means it now
> also manages BrowserThread::SetIOThreadDelegate())
> * BrowserProcessSubThread can be brought up early before being bound to
> a BrowserThread::ID (BrowserMainLoop handles that through
> BrowserProcessSubThread ::RegisterAsBrowserThread())
>
> Unfortunate exceptions required for this CL:
> * IOThread::Init() (invoked through BrowserThreadDelegate) perfoms
> blocking operations this was previously performed before installed
> the ThreadRestrictions on BrowserThread::IO. But now that //content
> is initialized after bringing up the thread, a
> base::ScopedAllowBlocking is required in scope of IOThread::Init().
> * TestBrowserThread previously bypassing BrowserProcessSubThread by
> directly subclassing BrowserThreadImpl meant it wasn't subject to
> ThreadRestrictions (unfortunate becomes it denies allowance
> verification to product code running in unit tests). Adding it back
> causes DCHECKs, as such
> BrowserProcessSubThread::AllowBlockingForTesting was added to allow
> this CL to pass CQ.
>
> Of note:
> * BrowserProcessSubThread is still written as though it supports many
> BrowserThread::IDs but in practice it's mostly always
> BrowserThread::IO (except in ThreadWatcherTest I think). This change
> was big enough that I didn't bother also breaking that
> generalization.
> * BrowserThreadImpl's constructor was made private to ensure only
> BrowserProcessSubThread and a few select callers get to drive it (to
> avoid previous missed initialization issues)
> * Atomics to manage BrowserThread::SetIOThreadDelegate were removed.
> Restriction was instead added that this only be called before
> initialization and after shutdown (this was already the case).
>
> Follow-ups to this CL:
> * //ios duplicates this logic and will need to undergo the same change
> as a follow-up
> * Fixing ios will allow removal of base::Thread::SetMessageLoop hack :)
> * Removing BrowserThreadGlobals::lock_ to address crbug.com/821034 will
> be much easier
> * BrowserThread post APIs should DCHECK rather than no-op if using a
> BrowserThread::ID before it's registered.
>
> Bug: 815225, 821034, 729596
> Change-Id: If1038f23079df72203b1e95c7d26647f8824a726
> Reviewed-on: https://chromium-review.googlesource.com/969104
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#544440}
TBR=jam@chromium.org
Bug: 815225, 821034, 729596, 824716
Change-Id: I9a180975c69a008f8519d1d3d44663aa58a74a92
Reviewed-on: https://chromium-review.googlesource.com/980793
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546104}
This reverts commit d260e9cf66.
Reason for revert: In Windows Canary versions since 67.0.3377.0, where this commit landed, IO thread hang reports have spiked dramatically. It is now the #1 browser crash report on Windows Canary at 33% of reports. I'm speculatively reverting this to see if the crash rate heals.
Original change's description:
> Refactor BrowserThreadImpl, BrowserProcessSubThread, and BrowserMainLoop
>
> This brings back the invariant that BrowserThread::IO isn't available
> before BrowserMainLoop::CreateThreads(). This was broken to fix issue
> 729596 to bring up the thread earlier for ServiceManager but it is
> important that code that posts to BrowserThread::IO statically have an
> happens-after relationship to BrowserMainLoop::CreateThreads(). Exposing
> it statically earlier put that invariant at risk.
>
> Thankfully fixing issue 815225 resulted in finally reaching the long
> sought goal of only having BrowserThread::UI/IO. Now that the IO thread
> is also kicked off before it's named statically, BrowserThreadImpl no
> longer needs to be a base::Thread, hence this refactoring.
>
> Before this CL:
> * BrowserThreadImpl was a base::Thread
> (could be a fake thread if SetMessageLoop was used)
> * BrowserProcessSubThread was a BrowserThreadImpl
> (performed a bit more initialization)
> * BrowserProcessSubThread was only used in production (in
> BrowserMainLoop)
> * BrowserThreadImpl was used for fake threads (BrowserMainLoop for
> BrowserThread::UI) and for testing (TestBrowserThread(Impl)).
> * BrowserThreadImpl overrode Init/Run/CleanUp() from base::Thread to
> perform some sanity checks as well as drive IOThread's Delegate (ref.
> BrowserThread::SetIOThreadDelegate())
> * BrowserProcessSubThread re-overrode Init/Run/CleanUp() to perform
> per-thread //content initialization (tests missed out on that per
> TestBrowserThread bypassing BrowserProcessSubThread by directly
> subclassing BrowserThreadImpl).
>
> With this CL:
> * BrowserThreadImpl is merely a scoped object that binds a provided
> SingleThreadTaskRunner to a BrowserThread::ID.
> * BrowserProcessSubThread is a base::Thread and performs all of the
> initialization and cleanup specific to //content (this means it now
> also manages BrowserThread::SetIOThreadDelegate())
> * BrowserProcessSubThread can be brought up early before being bound to
> a BrowserThread::ID (BrowserMainLoop handles that through
> BrowserProcessSubThread ::RegisterAsBrowserThread())
>
> Unfortunate exceptions required for this CL:
> * IOThread::Init() (invoked through BrowserThreadDelegate) perfoms
> blocking operations this was previously performed before installed
> the ThreadRestrictions on BrowserThread::IO. But now that //content
> is initialized after bringing up the thread, a
> base::ScopedAllowBlocking is required in scope of IOThread::Init().
> * TestBrowserThread previously bypassing BrowserProcessSubThread by
> directly subclassing BrowserThreadImpl meant it wasn't subject to
> ThreadRestrictions (unfortunate becomes it denies allowance
> verification to product code running in unit tests). Adding it back
> causes DCHECKs, as such
> BrowserProcessSubThread::AllowBlockingForTesting was added to allow
> this CL to pass CQ.
>
> Of note:
> * BrowserProcessSubThread is still written as though it supports many
> BrowserThread::IDs but in practice it's mostly always
> BrowserThread::IO (except in ThreadWatcherTest I think). This change
> was big enough that I didn't bother also breaking that
> generalization.
> * BrowserThreadImpl's constructor was made private to ensure only
> BrowserProcessSubThread and a few select callers get to drive it (to
> avoid previous missed initialization issues)
> * Atomics to manage BrowserThread::SetIOThreadDelegate were removed.
> Restriction was instead added that this only be called before
> initialization and after shutdown (this was already the case).
>
> Follow-ups to this CL:
> * //ios duplicates this logic and will need to undergo the same change
> as a follow-up
> * Fixing ios will allow removal of base::Thread::SetMessageLoop hack :)
> * Removing BrowserThreadGlobals::lock_ to address crbug.com/821034 will
> be much easier
> * BrowserThread post APIs should DCHECK rather than no-op if using a
> BrowserThread::ID before it's registered.
>
> Bug: 815225, 821034, 729596
> Change-Id: If1038f23079df72203b1e95c7d26647f8824a726
> Reviewed-on: https://chromium-review.googlesource.com/969104
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#544440}
TBR=gab@chromium.org,jam@chromium.org
NOPRESUBMIT=true
# Not skipping CQ checks because original CL landed > 1 day ago.
# falken: Skipping presubmit to use deprecated ThreadResrictions::DisallowWaiting().
Bug: 815225, 821034, 729596
Change-Id: I2be97c5d8183497c005ab397c871f625b034d850
Reviewed-on: https://chromium-review.googlesource.com/979752
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545725}
This brings back the invariant that BrowserThread::IO isn't available
before BrowserMainLoop::CreateThreads(). This was broken to fix issue
729596 to bring up the thread earlier for ServiceManager but it is
important that code that posts to BrowserThread::IO statically have an
happens-after relationship to BrowserMainLoop::CreateThreads(). Exposing
it statically earlier put that invariant at risk.
Thankfully fixing issue 815225 resulted in finally reaching the long
sought goal of only having BrowserThread::UI/IO. Now that the IO thread
is also kicked off before it's named statically, BrowserThreadImpl no
longer needs to be a base::Thread, hence this refactoring.
Before this CL:
* BrowserThreadImpl was a base::Thread
(could be a fake thread if SetMessageLoop was used)
* BrowserProcessSubThread was a BrowserThreadImpl
(performed a bit more initialization)
* BrowserProcessSubThread was only used in production (in
BrowserMainLoop)
* BrowserThreadImpl was used for fake threads (BrowserMainLoop for
BrowserThread::UI) and for testing (TestBrowserThread(Impl)).
* BrowserThreadImpl overrode Init/Run/CleanUp() from base::Thread to
perform some sanity checks as well as drive IOThread's Delegate (ref.
BrowserThread::SetIOThreadDelegate())
* BrowserProcessSubThread re-overrode Init/Run/CleanUp() to perform
per-thread //content initialization (tests missed out on that per
TestBrowserThread bypassing BrowserProcessSubThread by directly
subclassing BrowserThreadImpl).
With this CL:
* BrowserThreadImpl is merely a scoped object that binds a provided
SingleThreadTaskRunner to a BrowserThread::ID.
* BrowserProcessSubThread is a base::Thread and performs all of the
initialization and cleanup specific to //content (this means it now
also manages BrowserThread::SetIOThreadDelegate())
* BrowserProcessSubThread can be brought up early before being bound to
a BrowserThread::ID (BrowserMainLoop handles that through
BrowserProcessSubThread ::RegisterAsBrowserThread())
Unfortunate exceptions required for this CL:
* IOThread::Init() (invoked through BrowserThreadDelegate) perfoms
blocking operations this was previously performed before installed
the ThreadRestrictions on BrowserThread::IO. But now that //content
is initialized after bringing up the thread, a
base::ScopedAllowBlocking is required in scope of IOThread::Init().
* TestBrowserThread previously bypassing BrowserProcessSubThread by
directly subclassing BrowserThreadImpl meant it wasn't subject to
ThreadRestrictions (unfortunate becomes it denies allowance
verification to product code running in unit tests). Adding it back
causes DCHECKs, as such
BrowserProcessSubThread::AllowBlockingForTesting was added to allow
this CL to pass CQ.
Of note:
* BrowserProcessSubThread is still written as though it supports many
BrowserThread::IDs but in practice it's mostly always
BrowserThread::IO (except in ThreadWatcherTest I think). This change
was big enough that I didn't bother also breaking that
generalization.
* BrowserThreadImpl's constructor was made private to ensure only
BrowserProcessSubThread and a few select callers get to drive it (to
avoid previous missed initialization issues)
* Atomics to manage BrowserThread::SetIOThreadDelegate were removed.
Restriction was instead added that this only be called before
initialization and after shutdown (this was already the case).
Follow-ups to this CL:
* //ios duplicates this logic and will need to undergo the same change
as a follow-up
* Fixing ios will allow removal of base::Thread::SetMessageLoop hack :)
* Removing BrowserThreadGlobals::lock_ to address crbug.com/821034 will
be much easier
* BrowserThread post APIs should DCHECK rather than no-op if using a
BrowserThread::ID before it's registered.
Bug: 815225, 821034, 729596
Change-Id: If1038f23079df72203b1e95c7d26647f8824a726
Reviewed-on: https://chromium-review.googlesource.com/969104
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544440}
Missing includes are blocking a bigger upcoming change that
removes browser_thread.h from other places which tend to have a far
reach.
This removal was done by a script which adds browser_thread.h if
the file has "BrowserThread::" on a line which isn't a comment.
If the file is a header it also substracts the include from matching .cc
file if any.
If the file is a .cc it omits the include if it's already in the
matching .h
Minor exceptions :
* files that already included test_browser_thread.h (not doing so
broke DEPS as some tests are explicitly allowed to include
test_browser_thread.h but no content/public)
* chrome/renderer/chrome_content_renderer_client_browsertest.cc
(because it violates DEPS already by using BrowserThread:: from
content/renderer but this CL doesn't aim to fix tricky use cases)
TBR=jam@chromium.org
Bug: 815225, 821034
Change-Id: I5274433918c85f26caaa5b99adb990f07222fb99
Reviewed-on: https://chromium-review.googlesource.com/967186
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543834}
In this CL, we split the creation of the BrowserThread::IO thread and
initialization of its delegate:
1. The BrowserThread::IO is created in the
BrowserMainLoop::PostMainMessageLoopStart() after the UI thread
is created. Adjust the tracing events in the BrowserMainLoop.
2. Simplify the logic in BrowserMainLoop::CreateThreads() since only
the launcher thread is created there. Initializes the
delegate of the BrowserThread::IO there.
3. Update the logic in the BrowserThreadImpl when checking whether
the BrowserThread::IO has initialized.
4. Update BrowserMainLoopTest and BrowserProcessImplTest.
This is the first step of starting ServiceManager earlier.
Bug: 729596
Change-Id: I7a08fd7c7bf5548f8039c8c38152ecfde3bd20c4
Reviewed-on: https://chromium-review.googlesource.com/905424
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537318}
Outside of the browser thread, workers are always used to help the main
thread, which is always busy and the highest priority. Reserving a
core for the main thread makes sense (v8 traces show that the additional
worker doesn't get scheduled much by the OS and when it does it
preempts the main thread).
R=fdoray@chromium.org
Bug: 808028
Change-Id: Iaef9141c6ec271c46ae9c90d9fa625cab5c128e6
Reviewed-on: https://chromium-review.googlesource.com/897528
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534414}
BrowserMainLoop shuts down its BrowserThreadImpls, but SHUTDOWN is a
distinct state from UNINITIALIZED which is what BrowserThreadImpl expects
on initialization in the next test. Use ResetGlobalsForTesting() to
clear up lingering state.
This showed up on Fuchsia, but was cross-platform.
Bug: 759793, 754861
Change-Id: I2ffa5226e92e583ae317b8fb9f31bfce3e8e32ef
Reviewed-on: https://chromium-review.googlesource.com/639332
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498723}
SchedulerWorkerPoolImpl::GetMaxConcurrentTasksDeprecated is renamed to
GetMaxConcurrentNonBlockedTasksDeprecated and
TaskSchedueler::GetMaxConcurrentTasksWithTraitsDeprecated is
renamed to GetMaxConcurrentNonBlockedTasksWithTraitsDeprecated.
The function is used to determine the number of available background
threads in v8. But, with the advent of
ScopedBlockingCall, the max number of concurrent tasks actually changes
with threads being blocked. However, the maximum number of non-blocked
threads stays the same and is more applicable for current use cases
of the function.
TBR=jochen@chromium.org
Bug: 738104
Change-Id: I1b465f7155c85852ab4a361674755afc27b19817
Reviewed-on: https://chromium-review.googlesource.com/594208
Commit-Queue: Jeffrey He <jeffreyhe@google.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Reviewed-by: Francois Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496749}
For optimal performance, a renderer needs as many threads in the
foreground pool as there are cores on the machine. RenderProcessImpl
configures the number of threads in the foreground pool correctly for
renderer processes. In the case where renderers live in the browser
process, the code added by this CL adjusts the number of threads in the
foreground pool of the browser process.
The associated bug is a perf regression on single-process
android_webview caused by a migration of renderer tasks from
base::WorkerPool (which can have an infinite number of threads)
to the foreground pool of TaskScheduler (which :
- has max(2, num_cores) threads in a renderer process
- had x = min(8, max(3, 0.3 * num_cores)) threads in a
browser process prior to this CL
- has max(x, num_cores) in a --single-process browser
process with this CL
).
Discussion about single-process on android_webview:
https://groups.google.com/a/chromium.org/d/msg/android-webview-dev/QTFdKg0oR_U/K5f99jeCBAAJ
Bug: 727573
Change-Id: I2c6e1265dc9b39bddd66c0601683db702f943bda
Reviewed-on: https://chromium-review.googlesource.com/521262
Commit-Queue: Francois Doray <fdoray@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#480454}
