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 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}
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}
This changes the form of DoNothing() from a simple no-arg function to a class
that produces callbacks via templated operator(). This allows callers to
replace base::Bind(&base::DoNothing) with base::DoNothing() for a small
boilerplate reduction; more importantly, it allows using DoNothing() to replace
existing no-op functions/lambdas that took more than zero args, and thus had to
be manually declared. This removes dozens of such functions and around 600 LOC
total.
In a few places, DoNothing() can't be used directly, and this change also adds
explicit callback-generating Once<>() and Repeatedly<>() members that will
produce a callback with a specific signature.
BUG=811554
TEST=none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_mojo;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_vr;master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I37f87b35c6c079a6a8c03ff18ec3a54e1237f126
Reviewed-on: https://chromium-review.googlesource.com/903416
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538953}
This CL applies //tools/clang/base_bind_rewriters to //content/browser/{a,b,c,d,f,g}*
It rewrites base::Bind to base::BindOnce where the resulting base::Callback
is immediately converted to base::OnceCallback, which is considered safe
to use base::BindOnce.
E.g.:
base::PostTask(FROM_HERE, base::Bind([]{}));
base::OnceClosure cb = base::Bind([]{});
are converted to:
base::PostTask(FROM_HERE, base::BindOnce([]{}));
base::OnceClosure cb = base::BindOnce([]{});
Change-Id: I11ae9ac169c8e0ff9d9b95452fec22a8b7c91df7
NOPRESUBMIT=true
Change-Id: I11ae9ac169c8e0ff9d9b95452fec22a8b7c91df7
Reviewed-on: https://chromium-review.googlesource.com/628003
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496656}
And added runloop.h alongside message_loop.h in allowed //base dependencies
in Blink platform code as RunLoop is effectively an extension of
MessageLoop and I don't see a reason not to allow it.
TBR: danakj@chromium.org (for the scripted change)
TBR: kinuko@chromium.org (for third_party\Webkit\Source\platform\DEPS tweak)
Bug: 748715
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;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: I36c934a0f22e3ee7ff44d3efb80c6a1fe710b7b5
Reviewed-on: https://chromium-review.googlesource.com/585732
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489617}
BrowserThreadImpl states need to be cleaned up between tests,
otherwise the subsequent tests will crash trying to reinitialize BrowserThreadImpl.
This CL make sure that this is done correctly.
BUG=697560
Review-Url: https://codereview.chromium.org/2721223004
Cr-Commit-Position: refs/heads/master@{#454321}
In preparation for the migration of the FILE thread to TaskScheduler,
we want to disable destruction observers on it.
BrowserThreadTest.RunsTasksOnCurrentThreadDuringShutdown is the only
test that fails when destruction observers are disabled on the FILE
thread. This CL changes this test to use the UI thread instead.
BUG=653916
Review-Url: https://codereview.chromium.org/2399413003
Cr-Commit-Position: refs/heads/master@{#424151}
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}
This CL makes the following replacements in
content:
Before After
----------------------------------------------------------
x.PostTask() x.task_runner()->PostTask()
PostDelayedTask() PostDelayedTask()
ReleaseSoon() ReleaseSoon()
DeleteSoon() DeleteSoon()
x->PostTask() y->task_runner()->PostTask()
PostDelayedTask() PostDelayedTask()
ReleaseSoon() ReleaseSoon()
DeleteSoon() DeleteSoon()
x.Run() RunLoop().Run()
x.RunUntilIdle() RunLoop().RunUntilIdle()
x->Run() RunLoop().Run()
x->RunUntilIdle() RunLoop().RunUntilIdle()
If |y| isn't MessageLoopForUI::current() or
MessageLoopForIO::current()
y.message_loop()->task_runner()
y.task_runner()
y->message_loop()->task_runner()
y->task_runner()
----------------------------------------------------------
|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO). |y| is a base::Thread
or a pointer to a base::Thread.
This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.
This CL doesn't change code behavior.
BUG=616447
R=jam@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
Review-Url: https://codereview.chromium.org/2082343002
Cr-Commit-Position: refs/heads/master@{#403787}
The Google C++ style guide states:
Explicitly annotate overrides of virtual functions or virtual
destructors with an override or (less frequently) final specifier.
Older (pre-C++11) code will use the virtual keyword as an inferior
alternative annotation. For clarity, use exactly one of override,
final, or virtual when declaring an override.
To better conform to these guidelines, the following constructs have
been rewritten:
- if a base class has a virtual destructor, then:
virtual ~Foo(); -> ~Foo() override;
- virtual void Foo() override; -> void Foo() override;
- virtual void Foo() override final; -> void Foo() final;
This patch was automatically generated. The clang plugin can generate
fixit hints, which are suggested edits when it is 100% sure it knows how
to fix a problem. The hints from the clang plugin were applied to the
source tree using the tool in https://codereview.chromium.org/598073004.
BUG=417463
R=nasko@chromium.org
Review URL: https://codereview.chromium.org/678073006
Cr-Commit-Position: refs/heads/master@{#301534}
This keeps the forwarding header, just updates all current callers.
BUG=
R=avi@chromium.org
Review URL: https://codereview.chromium.org/16514006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205306 0039d316-1c4b-4281-b951-d872f2087c98
base/task.h is going away and being replaced by base/bind.h and base/callback.h.
This CL was automatically generated by sed.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/8872030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@113894 0039d316-1c4b-4281-b951-d872f2087c98
Only content/ now has the ability to create BrowserThread objects,
with the exception that tests can create the
content::TestBrowserThread subclass, and (temporarily) code in chrome/
can create the DeprecatedBrowserThread subclass.
A follow-up change will make content/ take care of its own thread
creation, remove DeprecatedBrowserThread, and move all state and
non-trivial constructors from BrowserThread down to BrowserThreadImpl.
Also moved BrowserProcessSubThread into content/ namespace. As part
of follow-up cleanup, chrome/ will stop using this class.
BUG=98716
TEST=existing
Review URL: http://codereview.chromium.org/8392042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107718 0039d316-1c4b-4281-b951-d872f2087c98
This ensures that the request/reply closures are always deleted on the origin
thread, or leaked if the task cannot be completed (due to message loop
shutdown).
BUG=86301
TEST=new unittests
Review URL: http://codereview.chromium.org/7210053
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@97387 0039d316-1c4b-4281-b951-d872f2087c98
