This CL was generated by using tools/git/move_source_file.py to change
the includes for those files:
base/bind_post_task.h
base/deferred_sequenced_task_runner.h
base/post_task_and_reply_with_result_internal.h
base/sequenced_task_runner.h
base/sequenced_task_runner_helpers.h
base/single_thread_task_runner.h
base/task_runner.h
base/task_runner_util.h
base/updateable_sequenced_task_runner.h
Then formatted using "git cl format". DEPS files were fixed with a
simple search and replace script.
Bug: 1255932
Change-Id: I0d9b5ddd9260fde5e4581e6c6e0080bdb0ed2c44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3209175
Reviewed-by: Gabriel Charette <gab@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#929867}
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 is
1) s/TestBrowserThreadBundle/BrowserTaskEnvironment/ on src/
2) s/([^/])\b\w*thread_bundle(_)?/\1task_environment\2/ on files modified in (1)
3) git cl format
4) Manually fix up remainder "ThreadBundle" and "thread_bundle" found via
string search on the whole of src/.
For ease of review:
* Step #3 is the diff between patch sets 1..2
* Step #4 is the diff between patch sets 2..3
TBR=dcheng@chromium.org
(for post-review owners bypass per mechanical change)
Bug: 992483
Change-Id: I4945141f6d78bdc6c98444198e5012ddc8e5bff0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1758440
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#688755}
*** 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 removes BrowserThread::Post(NonNestable|)(Delayed|)Task and moves
GetTaskRunnerForThread into the impl (it's still used to vend
TaskRunners in BrowserTaskExecutor).
These methods have been replaced by base/post_task.h in conjunction
with content/public/browser/browser_task_traits.h
Bug: 878356
Change-Id: Ia122dc0921769f43da9271ddd6e1ce2f402df779
Reviewed-on: https://chromium-review.googlesource.com/1235728
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592879}
Sampling profiler highlights high contention on this lock:
crbug.com/821034.
Initializing/tear down was already single-threaded (tear down had to be moved
from BrowserProcessSubThread::Cleanup() to ~BrowserProcessSubThread() to
enforce this with a ThreadChecker however). Add dchecks to confirm/enforce
this and remove the lock which is usuless on data structures that are now (as
of series of changes over the last year) read-only after startup.
Use atomics to protect reads across the RUNNING=>SHUTDOWN boundary.
Bug: 821034
Change-Id: I7800048bff51ad79cb10ee89fd3a0a31534c393e
Reviewed-on: https://chromium-review.googlesource.com/973556
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546212}
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}
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}
This reverts commit 6127a86f3a.
Reason for revert: Suspect this caused spike in ThreadWatcher hang reports: crbug.com/768886
Original change's description:
> Remove all remaining deprecated Web/BrowserThreads!!
>
> (except BrowserThread::FILE which has a handful use cases left still and
> will follow suit shortly)
>
> (BrowserThread::PROCESS_LAUNCHER migration was put on hold because of
> Android specific requirements around process launching)
>
> Remaining usage of TestBrowserThreadBundle::REAL_DB_THREAD could simply
> be removed as all of the product code was already migrated to TaskScheduler
> which always uses real threads in unit tests.
>
> Bug: 689520, 365909, 752144
> Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester
> Change-Id: Id70b722aa35e8568795d5aac16947392ac1597be
>
> NOPRESUBMIT=True (for content/browser/browser_thread_impl.cc:211)
>
> Change-Id: Id70b722aa35e8568795d5aac16947392ac1597be
> Reviewed-on: https://chromium-review.googlesource.com/610880
> Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#503732}
TBR=gab@chromium.org,jam@chromium.org,dpranke@chromium.org,asvitkine@chromium.org,sdefresne@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
NOPRESUBMIT=True (for restoring the deprecated browser threads)
Bug: 689520, 365909, 752144, 768886
Change-Id: I53d93572118303743e1dde71b2a473350717b215
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester
Reviewed-on: https://chromium-review.googlesource.com/689254
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504939}
(except BrowserThread::FILE which has a handful use cases left still and
will follow suit shortly)
(BrowserThread::PROCESS_LAUNCHER migration was put on hold because of
Android specific requirements around process launching)
Remaining usage of TestBrowserThreadBundle::REAL_DB_THREAD could simply
be removed as all of the product code was already migrated to TaskScheduler
which always uses real threads in unit tests.
Bug: 689520, 365909, 752144
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester
Change-Id: Id70b722aa35e8568795d5aac16947392ac1597be
NOPRESUBMIT=True (for content/browser/browser_thread_impl.cc:211)
Change-Id: Id70b722aa35e8568795d5aac16947392ac1597be
Reviewed-on: https://chromium-review.googlesource.com/610880
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503732}
These threads are deprecated and no longer used.
NOPRESUBMIT=true
Bug: 689520
Change-Id: I55b05b70626f91c8a71d56642c851bb786dbfcaa
Reviewed-on: https://chromium-review.googlesource.com/660597
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Francois Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501245}
This maintains some forward declarations so all >400 uses don't need to be
updated at the same time.
This patch changes all forward declarations and code that depends on them.
BUG=763556
TBR=stevenjb@chromium.org (chromeos/network)
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Icabd948fe9e0881fdb60db38b31a9d0763867bc4
Reviewed-on: https://chromium-review.googlesource.com/657249
Reviewed-by: Brett Wilson <brettw@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Brett Wilson <brettw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501092}
After this CL, TaskRunner::PostTask and its family can take OnceClosure
in addition to Closure.
Most of the changes are mechanical replacement of Closure with OnceClosure
on TaskRunner family. Others are:
- Limit CriticalClosure from Closure to OnceClosure as no caller call
the resulting callback more than once
- Add several PostTaskAndReplyWithResult overloads for old Callback
version, for compatibility. (in base/task_scheduler/post_task.h)
- Update SequencedWorkerPool implementation for OnceClosure.
- Update task handling code in app_state.mm for OnceClosure, which is
needed to bring OnceClosure into a ObjC block.
BUG=704027
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2637843002
Cr-Commit-Position: refs/heads/master@{#462023}
This is a preparation CL for http://crrev.com/2637843002, which replaces
the Callback parameter of TaskRunner::PostTask with OnceCallback.
This one replaces the passed-by-const-ref Callback parameter of
TaskRunner::PostTask() with pass-by-value.
With the pass-by-const-ref manner as the old code does, we can't avoid
leaving a reference to the callback object on the original thread. That
is, the callback object may be destroyed either on the target thread or
the original thread. That's problematic when a non-thread-safe object is
bound to the callback.
Pass-by-value and move() in this CL mitigate the nondeterminism: if the
caller of TaskRunner::PostTask() passes the callback object as rvalue,
TaskRunner::PostTask() leaves no reference on the original thread.
I.e. the reference is not left if the callback is passed directly from
Bind(), or passed with std::move() as below.
task_runner->PostTask(FROM_HERE, base::Bind(&Foo));
base::Closure cb = base::Bind(&Foo);
task_runner->PostTask(FROM_HERE, std::move(cb));
Otherwise, if the caller passes the callback as lvalue, a reference to
the callback is left on the original thread as we do in the previous code.
I.e. a reference is left if the callback is passed from other non-temporary
variable.
base::Closure cb = base::Bind(&Foo);
task_runner->PostTask(FROM_HERE, cb);
This is less controversial part of http://crrev.com/2637843002. This CL
is mainly to land it incrementally.
TBR=shrike@chromium.org
BUG=704027
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2726523002
Cr-Commit-Position: refs/heads/master@{#460288}
This is part of the migration phase for TaskScheduler, design doc:
https://docs.google.com/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa5k/edit
Also generalizes BrowserThreadImpl away from the underlying thread's MessageLoop
and id in favor of TaskRunners and BrowserThreadState.
Cool side-effect: BrowserThreadImpl::StartWithOptions() no longer blocks on the
underlying thread starting (it used to via GetThreadId()), it now takes a reference
to its TaskRunner and lets the thread itself start on its own schedule :).
This wasn't previously intended to block (BrowserThreadImpl::StartAndWaitForTesting() is
supposed to be used for that) but had unintentionally regressed in http://crrev.com/408295
because GetThreadId() implicitly waits (http://crbug.com/672977).
Another nice improvement is that ~BrowserThreadImpl() now cleans the BrowserThreadGlobals
associated with it, this has the side-effect to force proper destruction order of
TestBrowserThread in tests which brought forth a few precursor cleanups
(https://crbug.com/653916#c24) which will from now on be enforced by this CL.
When redirection is disabled, the logic should be the exact same as before.
- Threads are brought up.
- Tasks are posted to their MessageLoop (albeit through their TaskRunner now).
- On shutdown, threads are joined one by one.
When redirection is enabled, we try to mimic this logic.
- Redirection TaskRunners are only live (|accepting_tasks|) for the same period that the
matching thread would be.
- On shutdown, we block on each TaskRunner's queue being flushed one-by-one
in the same order as in the no-redirection case (this almost identical to
real threads join % one slight difference documented in detail in
BrowserThreadImpl::StopRedirectionOfThreadID()).
BUG=653916, 672977
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_tsan_rel_ng
TEST=
A) "out\Release\chrome.exe"
Runs/shuts down the exact same as before.
B) "out\Release\chrome.exe --force-fieldtrials=BrowserScheduler/Enabled/ --force-fieldtrial-params=BrowserScheduler.Enabled:Background/3;3;1;0;10000/BackgroundFileIO/3;3;1;0;10000/Foreground/3;3;1;0;10000/ForegroundFileIO/3;3;1;0;10000/RedirectSequencedWorkerPools/true/RedirectNonUINonIOBrowserThreads/true"
Runs/shuts down smoothly and chrome://tracing confirms that redirected BrowserThreads are running on TaskSchedulerWorkers.
Review-Url: https://codereview.chromium.org/2464233002
Cr-Commit-Position: refs/heads/master@{#439139}
Instantiating a BrowserThreadImpl sets global state which leaks to the next
tests. This is a problem in https://codereview.chromium.org/2464233002/ where
a reset was introduced for tests (driven by TestBrowserThread).
Tests should already have been using TestBrowserThread over BrowserThreadImpl
and today TestBrowserThreadBundle is favored over TestBrowserThread so it is
used as the replacement in this CL.
BUG=653916
Review-Url: https://codereview.chromium.org/2487073005
Cr-Commit-Position: refs/heads/master@{#431070}
Changes BrowserThread::CurrentlyOn (and thus
BrowserThreadTaskRunner::RunsTasksOnCurrentThread()) to correctly report
a BrowserThread's association during MessageLoop destruction notification.
Also adds an explicit Start() to BrowserThreadImpl as there are tests which
call it and which incorrectly assumed base::Thread's implementation would
call BrowserThreadImpl::StartWithOptions (which it wouldn't since the latter
is not a virtual function.)
This change provokes many tests to delete ExtensionFunction instances that
were otherwise being leaked because UIThreadExtensionFunction::Destroy was
incorrectly deferring destruction when run on the UI thread during shutdown.
This in turn revealed a few small bugs which have also been fixed here.
BUG=631093
R=jam@chromium.org
Committed: https://crrev.com/b02da29fb9116d1a1fb4fd0476628f333ff6bd1a
Review-Url: https://codereview.chromium.org/2180253003
Cr-Original-Commit-Position: refs/heads/master@{#408295}
Cr-Commit-Position: refs/heads/master@{#408411}
Reason for revert:
Test failures in the changes to the ComponentCloudPolicyTest. Doh.
Original issue's description:
> Ensure BrowserThread::CurrentlyOn is correct through MessageLoop teardown
>
> Changes BrowserThread::CurrentlyOn (and thus
> BrowserThreadTaskRunner::RunsTasksOnCurrentThread()) to correctly report
> a BrowserThread's association during MessageLoop destruction notification.
>
> Also adds an explicit Start() to BrowserThreadImpl as there are tests which
> call it and which incorrectly assumed base::Thread's implementation would
> call BrowserThreadImpl::StartWithOptions (which it wouldn't since the latter
> is not a virtual function.)
>
> This change provokes many tests to delete ExtensionFunction instances that
> were otherwise being leaked because UIThreadExtensionFunction::Destroy was
> incorrectly deferring destruction when run on the UI thread during shutdown.
> This in turn revealed a few small bugs which have also been fixed here.
>
> BUG=631093
> R=jam@chromium.org
>
> Committed: https://crrev.com/b02da29fb9116d1a1fb4fd0476628f333ff6bd1a
> Cr-Commit-Position: refs/heads/master@{#408295}
TBR=jam@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=631093
Review-Url: https://codereview.chromium.org/2186213002
Cr-Commit-Position: refs/heads/master@{#408311}
Changes BrowserThread::CurrentlyOn (and thus
BrowserThreadTaskRunner::RunsTasksOnCurrentThread()) to correctly report
a BrowserThread's association during MessageLoop destruction notification.
Also adds an explicit Start() to BrowserThreadImpl as there are tests which
call it and which incorrectly assumed base::Thread's implementation would
call BrowserThreadImpl::StartWithOptions (which it wouldn't since the latter
is not a virtual function.)
This change provokes many tests to delete ExtensionFunction instances that
were otherwise being leaked because UIThreadExtensionFunction::Destroy was
incorrectly deferring destruction when run on the UI thread during shutdown.
This in turn revealed a few small bugs which have also been fixed here.
BUG=631093
R=jam@chromium.org
Review-Url: https://codereview.chromium.org/2180253003
Cr-Commit-Position: refs/heads/master@{#408295}
Why?
The fact that there's a MessageLoop on the thread is an
unnecessary implementation detail. When browser threads
are migrated to base/task_scheduler, tasks will no longer
have access to a MessageLoop.
These changes were generated manually.
Note: Some files outside of base/ had to be modified
because they didn't compile anymore after
#include "base/message_loop/message_loop.h" was removed
from base/ headers.
BUG=616447
TBR=rogerta@chromium.org
Review-Url: https://codereview.chromium.org/2136563002
Cr-Commit-Position: refs/heads/master@{#406378}
Original review: https://codereview.chromium.org/1011683002/
2nd try: https://codereview.chromium.org/1129953004/
2nd try reverted due to race reports on Linux:
https://crbug.com/489263 Data races on valid_thread_id_ after r330329
This fixes:
- Race in MessageLoopProxyImpl by introducing lock
- Race in BrowserMainLoop/BrowserThreadImpl, where BrowserThread::CurrentlyOn()
called on one of BrowserThreads tries to touch other thread's message_loop()
via global thread table.
Reg: the latter race, the code flow that causes this race is like following:
// On the main thread, we create all known browser threads:
for (...) {
{
AutoLock lock(g_lock);
g_threads[id] = new BrowserProcessSubThread();
}
// [A] This initializes the thread's message_loop, which causes a race
// against [B] in the new code because new threads can start running
// immediately.
thread->StartWithOptions();
}
// On the new thread's main function, it calls CurrentlyOn() which does:
{
// [B] This touches other thread's Thread::message_loop.
AutoLock lock(g_lock);
return g_threads[other_thread_id] &&
g_threads[other_thread_id]->message_loop() == MessageLoop::current();
}
This was safe before because both message_loop initialization and the first
call to CurrentlyOn() on the new thread was done synchronously in
StartWithOptions() while the main thread was blocked. In the new code
new threads can start accessing message_loop() asynchronously while
the main thread's for loop is running.
PS1 is the original patch (2nd try) that got reverted.
BUG=465458, 489263
Review URL: https://codereview.chromium.org/1131513007
Cr-Commit-Position: refs/heads/master@{#331235}
This patch was automatically generated by applying clang fixit hints
generated by the plugin to the source tree.
BUG=417463
TBR=sky@chromium.org
Review URL: https://codereview.chromium.org/667943003
Cr-Commit-Position: refs/heads/master@{#300469}
This step is a giant search and replace for OVERRIDE and FINAL to
replace them with their lowercase versions.
BUG=417463
Review URL: https://codereview.chromium.org/637183002
Cr-Commit-Position: refs/heads/master@{#298804}
This will prevent tests that utilize a SimpleCache from running into teardown leaks.
BUG=413688
Review URL: https://codereview.chromium.org/562203002
Cr-Commit-Position: refs/heads/master@{#296936}
While we already flush the blocking pool in a OnTestEnd() hook (installed in
ContentTestSuiteBase), that is too late for tests that create their own threads.
The test (and the TestBrowserThreadBundle that it contains) will have been
destroyed by the time the hook runs, and any tasks posted to the blocking pool
via PostTaskAndReply will not be able to reply back to the originating thread.
This causes the task and reply Closures to be leaked. Flushing the blocking pool
before TestBrowserThreadBundle is destroyed should fix those leaks.
BUG=168415, 270673, 270658
TBR=ajwong@chromium.org, jochen@chromium.org
Review URL: https://codereview.chromium.org/22799005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@217268 0039d316-1c4b-4281-b951-d872f2087c98
This CL creates a new class, TestBrowserThreadBundle, that creates a TestBrowserThread for the most commonly needed BrowserThreads. It also adds this thread bundle into RenderViewHostTestHarness because most tests that use this harness need these threads in order to run. To support TestBrowserThreadBundle, BrowserThreadImpl's test construction was also modified to understand a NULL message_loop.
Aside from introducing the new class, this CL also removes:
(1) unnecessary constructors in test
(2) DISALLOW_COPY_AND_ASSIGNS in test fixtures*
(3) now redundant TestBrowserThreads from tests
(4) bad access-level changes for SetUp() and TearDown()
(5) using declarations that root off the global scope
(6) uses of MessageLoop's RunUntilIdle() and Quit()
(7) as many real threads as possible
There are also a changes to MediaCaptureDevicesDispatcher and OneClickSigninHelper that allow unittests to cut dependencies on IO thread activity. DesktopNotificationServiceTest (and a couple of others) were also made single threaded because the synchronization logic required for a non-flaky test meant the parallelism only really exercised the extra code in the test that forced the serialization.
* DISALLOW_COPY_AND_ASSIGN does not serve much purpose in GTest fixture types. However, using it removes the compile-provided default constructor which forces the fixture writer to provide an empty default constructor. Since GTest recommends the default constructor as the preferred method to do setup for a test (as opposed to the SetUp() method), it's confusing to have bunch of classes with both SetUp() and a default constructor. It's simpler and uses less code to just remove the DISALLOW_COPY_AND_ASSIGN. An alternative would be to use the default constructor for initialization, but this is not possible because of our test harnesses are inheritance based which means it is impossible for a derived fixture to perform initialization before the harness if we use the GTest preferred default constructor initialization pattern.
TBR=avi,battre,ben,benwells,brettw,dbeam,dimich,joi,joth,mad,marja,markusheintz,noelallen,phajdan,rdsmith,satorux,scherkus,sky,stevenjb,stuartmorgan,timsteele
BUG=159193
Review URL: https://chromiumcodereview.appspot.com/14197014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204603 0039d316-1c4b-4281-b951-d872f2087c98
The CL changes semantics and implementation of the existing FlushForTesting method (which wasn't suitable for this usage).
* The old method would wait for delayed tasks prior to continuing, the new method
will not run them but will delete them prior to continuing.
* The old method would deadlock if called after Shutdown had been called, the new method returns immediately in that case.
A few SWP unittests relied on the waiting for delayed task completion behavior. Those have been modified to explicitly wait thru other means.
BUG=168415,166470
Review URL: https://codereview.chromium.org/11649032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@186578 0039d316-1c4b-4281-b951-d872f2087c98
which make it possible to tell the thread name in crash dumps
from the call stack. Added a volatile automatic variable to
avoid global optimizers optimizing the function.
This change would help us to triage ThreadWatcher crashes
for IO thread. It would also help in debugging crashes.
R=sky, jar
Review URL: https://chromiumcodereview.appspot.com/10796079
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@147949 0039d316-1c4b-4281-b951-d872f2087c98
These functions add TimeDelta interfaces in addition to the int ms interfaces,
which will be removed at a later date.
BUG=108171
Review URL: http://codereview.chromium.org/9427023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@123683 0039d316-1c4b-4281-b951-d872f2087c98
[re-land of 116816 http://codereview.chromium.org/9065009]
This does some refactoring of the static data in the browser thread so we only have one global object instead of a bunch fo separate arrays.
It also hooks up the visited link master's I/O to use this new system as a proof of concept.
Review URL: https://chromiumcodereview.appspot.com/9124033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@118236 0039d316-1c4b-4281-b951-d872f2087c98
