Task Posting v3: migrate (Sequenced|Thread)TaskRunnerHandle
To migrate to v3 task posting API, this CL moves moves
(Sequenced|Thread)TaskRunnerHandle::Get() to
(Sequenced|SingleThread)TaskRunner::GetCurrentDefault()
and related classes. For more detail on this migration, refer to
https://docs.google.com/document/d/1tssusPykvx3g0gvbvU4HxGyn3MjJlIylnsH13-Tv6s4/edit#bookmark=id.1umyn7v5a4p
The blink codebase's presubmits were substantially changed. This was
done because the presubmit did not parse in-class identifiers, and so
there was no way of banning inner classes/methods/identifiers of a
class which is allowed.
The reason this was needed for this CL is that
base::(Sequenced|SingleThread)TaskRunners are permitted in blink, but
we need to ban (Sequenced|SingleThread)TaskRunner::GetCurrentDefault()
and [...]::CurrentDefaultHandle to ensure that tasks in blink remain
properly labeled.
To this end, a new type of identifier (in-class identifiers, such as
nested::namespace::ClassName::EnumClassName) is parsed by the
presubmit, and a new kind of rule can be added to the _CONFIG file to
allow/deny them. They are parsed very similarly to the existing
identifiers, but crucially, they are allowed by default, whereas
ClassNames are denied by default.
In addition, the tests for the presubmit were mostly rewritten to
properly test whether the identifiers in the test are actually
allowed/disallowed. Instead of simply testing to see whether an
identifier is present in _CONFIG in the presubmit file, the
presubmit's functions are called in the same way as happens during the
presubmit to make sure the code being run actually works.
Finally, it also tests that the identifiers tested are fully parsed
(a handful of them weren't because they were either preceded by '::'
or in-class) by the presubmit.
The task runner handle classes still exist in the codebase, and no
existing Chromium code has been modified, as semantics have been
preserved despite the implementation change.
The implementation migration will then take place in future CLs.
Because the two APIs expose the same functionality, the codebase
can be incrementally migrated.
Bug: 1026641
Change-Id: I7ea7bb36f30ecd3cdefedcffd8bae16118b0f3d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3804911
Reviewed-by: Francois Pierre Doray <[email protected]>
Commit-Queue: Sean Maher <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: Gabriel Charette <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1050813}
diff --git a/docs/threading_and_tasks_testing.md b/docs/threading_and_tasks_testing.md
index d66722ff..537c0879 100644
--- a/docs/threading_and_tasks_testing.md
+++ b/docs/threading_and_tasks_testing.md
@@ -40,10 +40,10 @@
### base::test::SingleThreadTaskEnvironment
-Your component uses `base::ThreadTaskRunnerHandle::Get()` or
-`base::SequencedTaskRunnerHandle::Get()` to post tasks to the thread it was
-created on? You'll need at least a `base::test::SingleThreadTaskEnvironment` in
-order for these APIs to be functional and `base::RunLoop` to run the posted
+Your component uses `base::SingleThreadTaskRunner::GetCurrentDefault()` or
+`base::SequencedTaskRunner::GetCurrentDefault()` to post tasks to the thread it
+was created on? You'll need at least a `base::test::SingleThreadTaskEnvironment`
+in order for these APIs to be functional and `base::RunLoop` to run the posted
tasks.
Typically this will look something like this:
@@ -52,7 +52,7 @@
```c++
class Foo {
public:
- Foo() : owning_sequence_(base::SequencedTaskRunnerHandle::Get()) {}
+ Foo() : owning_sequence_(base::SequencedTaskRunner::GetCurrentDefault()) {}
DoSomethingAndReply(base::OnceClosure on_done) {
DCHECK(owning_sequence_->RunsTasksInCurrentSequence());
