|
|
DescriptionUse TaskScheduler instead of SequencedWorkerPool in storage_partition_impl_map.cc.
SequencedWorkerPool is being deprecated in favor of TaskScheduler.
BUG=667892
R=clamy@chromium.org
Review-Url: https://codereview.chromium.org/2879963002
Cr-Commit-Position: refs/heads/master@{#472806}
Committed: https://chromium.googlesource.com/chromium/src/+/098c35c20b6879046acd7b2922751dc199c31bc6
Patch Set 1 #Patch Set 2 : fix-build-errors #Patch Set 3 : fix-build-errors #Patch Set 4 : fix-build-errors #Patch Set 5 : fix-build-errors #
Total comments: 2
Messages
Total messages: 37 (26 generated)
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Please take a look. This CL was generated automatically. The base::MayBlock() trait was specified for all call sites and the base::TaskPriority::BACKGROUND trait was specified for all non-test call sites. That may not be appropriate for your use case. Please verify that appropriate traits were used https://cs.chromium.org/chromium/src/base/task_scheduler/task_traits.h If everything looks good, lgtm and CQ this CL. Otherwise, tell us what's wrong. Thanks. - FAQ - What if bots are red? Ignore this CL. A human will look at errors shortly. What if the shutdown behavior is not set explicitly (no base::TaskShutdownBehavior)? If shutdown behavior is important for a task, it should be set explicitly. It's not necessary to specify it if you're fine with either BLOCK_SHUTDOWN or SKIP_ON_SHUTDOWN. Note that the default shutdown behavior is BLOCK_SHUTDOWN in SequencedWorkerPool and SKIP_ON_SHUTDOWN in TaskScheduler. What if the task priority is not set explicitly (no base::TaskPriority)? When there is no explicit priority, the priority is inherited from the calling context (e.g. a task posted from a BACKGROUND task without an explicit priority will have a BACKGROUND priority).
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
Description was changed from ========== Use TaskScheduler instead of SequencedWorkerPool in storage_partition_impl_map.cc. SequencedWorkerPool is being deprecated in favor of TaskScheduler. BUG=667892 R=clamy@chromium.org ========== to ========== Use TaskScheduler instead of SequencedWorkerPool in storage_partition_impl_map.cc. SequencedWorkerPool is being deprecated in favor of TaskScheduler. BUG=667892 R=clamy@chromium.org ==========
clamy@chromium.org changed reviewers: + nasko@chromium.org
@nasko: PTAL. I've seen that you've worked in the file before, and I want to check that the priority is the right one for this use case. Thanks!
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
On 2017/05/15 12:59:23, clamy (ooo until May 25) wrote: > @nasko: PTAL. I've seen that you've worked in the file before, and I want to > check that the priority is the right one for this use case. Thanks! There are failing checks in tests, please correct those and I'll take a look.
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by fdoray@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
On 2017/05/16 04:11:40, nasko (out) wrote: > On 2017/05/15 12:59:23, clamy (ooo until May 25) wrote: > > @nasko: PTAL. I've seen that you've worked in the file before, and I want to > > check that the priority is the right one for this use case. Thanks! > > There are failing checks in tests, please correct those and I'll take a look. Done. Please take a look.
fdoray@chromium.org changed reviewers: + jam@chromium.org
+jam@ since outer reviewers are ooo
+jam@ since other reviewers are ooo
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm if the answer to my question is no-new-thread https://codereview.chromium.org/2879963002/diff/80001/content/browser/storage... File content/browser/storage_partition_impl_map.cc (right): https://codereview.chromium.org/2879963002/diff/80001/content/browser/storage... content/browser/storage_partition_impl_map.cc:373: file_access_runner_(base::CreateSequencedTaskRunnerWithTraits( just to double check: this doesn't create a unique thread right? (would be good to make this clear in the comments for the method)
https://codereview.chromium.org/2879963002/diff/80001/content/browser/storage... File content/browser/storage_partition_impl_map.cc (right): https://codereview.chromium.org/2879963002/diff/80001/content/browser/storage... content/browser/storage_partition_impl_map.cc:373: file_access_runner_(base::CreateSequencedTaskRunnerWithTraits( On 2017/05/18 14:20:14, jam wrote: > just to double check: this doesn't create a unique thread right? (would be good > to make this clear in the comments for the method) No, it doesn't create a new thread. I will make this clearer in the documentation.
The CQ bit was checked by fdoray@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 80001, "attempt_start_ts": 1495119103414670, "parent_rev": "659da7906d9027de3e9eb0a436ea92b586e1f5d8", "commit_rev": "098c35c20b6879046acd7b2922751dc199c31bc6"}
Message was sent while issue was closed.
Description was changed from ========== Use TaskScheduler instead of SequencedWorkerPool in storage_partition_impl_map.cc. SequencedWorkerPool is being deprecated in favor of TaskScheduler. BUG=667892 R=clamy@chromium.org ========== to ========== Use TaskScheduler instead of SequencedWorkerPool in storage_partition_impl_map.cc. SequencedWorkerPool is being deprecated in favor of TaskScheduler. BUG=667892 R=clamy@chromium.org Review-Url: https://codereview.chromium.org/2879963002 Cr-Commit-Position: refs/heads/master@{#472806} Committed: https://chromium.googlesource.com/chromium/src/+/098c35c20b6879046acd7b292275... ==========
Message was sent while issue was closed.
Committed patchset #5 (id:80001) as https://chromium.googlesource.com/chromium/src/+/098c35c20b6879046acd7b292275... |