|
|
DescriptionUse TaskScheduler instead of blocking pool in mime_util.cc.
The blocking pool is being deprecated in favor of TaskScheduler.
BUG=667892
R=benwells@chromium.org
Review-Url: https://codereview.chromium.org/2675203004
Cr-Commit-Position: refs/heads/master@{#451757}
Committed: https://chromium.googlesource.com/chromium/src/+/147b9041c080e7620515541ca421cfc6426341e2
Patch Set 1 #Patch Set 2 : upload #Patch Set 3 : upload #
Total comments: 1
Patch Set 4 : no explicit priority #Messages
Total messages: 25 (15 generated)
Hi! I'm a Python script responsible for migrating tasks from the blocking pool to TaskScheduler. In this CL, I used these traits to post to TaskScheduler a task that was previously posted to the blocking pool: .WithPriority(base::TaskPriority::BACKGROUND) User won't notice if the task takes an arbitrarily long time to complete. Making your task BACKGROUND allows non-BACKGROUND tasks to run faster :) *No* .WithShutdownBehavior() .MayBlock() The task may block. This includes but is not limited to tasks that wait on synchronous file I/O operations: read or write a file from disk, interact with a pipe or a socket, rename or delete a file, enumerate files in a directory, etc. This trait isn't required for the mere use of locks. *No* .WithBaseSyncPrimitives() The task is not allowed to use these functions: - base::WaitableEvent::Wait - base::ConditionVariable::Wait - base::PlatformThread::Join - base::PlatformThread::Sleep - base::Process::WaitForExit - base::Process::WaitForExitWithTimeout If you think this is correct, please LGTM and CQ this CL. Otherwise, tell me which traits I should have used and I'll automatically upload a new patch. You can find documentation at https://cs.chromium.org/chromium/src/base/task_scheduler/task_traits.h WithPriority() [default/BACKGROUND/USER_VISIBLE/USER_BLOCKING]: WithShutdownBehavior() [default/CONTINUE_ON_SHUTDOWN/SKIP_ON_SHUTDOWN/BLOCK_SHUTDOWN]: MayBlock() [yes/no]: WithBaseSyncPrimitives() [yes/no]: Comments for a human: [A human will read this] FAQ: What should I do if the CQ dry run didn't pass? You can ignore this CL. A human will take a look and get back to you. Why are you doing this? Browser threads, the blocking pool and base::WorkerPool are being deprecated in favor of TaskScheduler. Design doc: https://docs.google.com/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa... What is the default priority? A task posted to TaskScheduler without an explicit priority inherits its priority from the calling context (e.g. a task posted to TaskScheduler from a BACKGROUND task without an explicit .WithPriority() will have a BACKGROUND priority). What is the default shutdown behavior? It is not documented on purpose. If your task shouldn't be skipped on shutdown (e.g. a task that persists user data on disk), it should have an explicit BLOCK_SHUTDOWN shutdown behavior. If it's important not to wait on your task on shutdown (e.g. it takes a long time to run and could cause a shutdown hang), it should have an explicit CONTINUE_ON_SHUTDOWN shutdown behavior.
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_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
Hi! I'm a Python script responsible for migrating tasks from the blocking pool to TaskScheduler. In this CL, I used these traits to post to TaskScheduler a task that was previously posted to the blocking pool: .WithPriority(base::TaskPriority::BACKGROUND) User won't notice if the task takes an arbitrarily long time to complete. Making your task BACKGROUND allows non-BACKGROUND tasks to run faster :) *No* .WithShutdownBehavior() .MayBlock() The task may block. This includes but is not limited to tasks that wait on synchronous file I/O operations: read or write a file from disk, interact with a pipe or a socket, rename or delete a file, enumerate files in a directory, etc. This trait isn't required for the mere use of locks. *No* .WithBaseSyncPrimitives() The task is not allowed to use these functions: - base::WaitableEvent::Wait - base::ConditionVariable::Wait - base::PlatformThread::Join - base::PlatformThread::Sleep - base::Process::WaitForExit - base::Process::WaitForExitWithTimeout If you think this is correct, please LGTM and CQ this CL. Otherwise, tell me which traits I should have used and I'll automatically upload a new patch. You can find documentation at https://cs.chromium.org/chromium/src/base/task_scheduler/task_traits.h WithPriority() [default/BACKGROUND/USER_VISIBLE/USER_BLOCKING]: WithShutdownBehavior() [default/CONTINUE_ON_SHUTDOWN/SKIP_ON_SHUTDOWN/BLOCK_SHUTDOWN]: MayBlock() [yes/no]: WithBaseSyncPrimitives() [yes/no]: Comments for a human: [A human will read this] FAQ: What should I do if the CQ dry run didn't pass? You can ignore this CL. A human will take a look and get back to you. Why are you doing this? Browser threads, the blocking pool and base::WorkerPool are being deprecated in favor of TaskScheduler. Design doc: https://docs.google.com/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa... What is the default priority? A task posted to TaskScheduler without an explicit priority inherits its priority from the calling context (e.g. a task posted to TaskScheduler from a BACKGROUND task without an explicit .WithPriority() will have a BACKGROUND priority). What is the default shutdown behavior? It is not documented on purpose. If your task shouldn't be skipped on shutdown (e.g. a task that persists user data on disk), it should have an explicit BLOCK_SHUTDOWN shutdown behavior. If it's important not to wait on your task on shutdown (e.g. it takes a long time to run and could cause a shutdown hang), it should have an explicit CONTINUE_ON_SHUTDOWN shutdown behavior.
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: This issue passed the CQ dry run.
On 2017/02/06 13:32:27, fdoray wrote: > Hi! I'm a Python script responsible for migrating tasks from the > blocking pool to TaskScheduler. In this CL, I used these traits to post to > TaskScheduler a task that was previously posted to the blocking pool: > > .WithPriority(base::TaskPriority::BACKGROUND) > User won't notice if the task takes an arbitrarily long time to complete. > Making your task BACKGROUND allows non-BACKGROUND tasks to run faster :) > > *No* .WithShutdownBehavior() > > .MayBlock() > The task may block. This includes but is not limited to tasks that wait on > synchronous file I/O operations: read or write a file from disk, interact > with a pipe or a socket, rename or delete a file, enumerate files in a > directory, etc. This trait isn't required for the mere use of locks. > > *No* .WithBaseSyncPrimitives() > The task is not allowed to use these functions: > - base::WaitableEvent::Wait > - base::ConditionVariable::Wait > - base::PlatformThread::Join > - base::PlatformThread::Sleep > - base::Process::WaitForExit > - base::Process::WaitForExitWithTimeout > > If you think this is correct, please LGTM and CQ this CL. > > Otherwise, tell me which traits I should have used and I'll automatically > upload a new patch. You can find documentation at > https://cs.chromium.org/chromium/src/base/task_scheduler/task_traits.h > > WithPriority() > [default/BACKGROUND/USER_VISIBLE/USER_BLOCKING]: > > WithShutdownBehavior() > [default/CONTINUE_ON_SHUTDOWN/SKIP_ON_SHUTDOWN/BLOCK_SHUTDOWN]: > > MayBlock() > [yes/no]: > > WithBaseSyncPrimitives() > [yes/no]: > > Comments for a human: > [A human will read this] > > FAQ: > > What should I do if the CQ dry run didn't pass? > You can ignore this CL. A human will take a look and get back to you. > > Why are you doing this? > Browser threads, the blocking pool and base::WorkerPool are being deprecated > in favor of TaskScheduler. Design doc: > https://docs.google.com/document/d/1S2AAeoo1xa_vsLbDYBsDHCqhrkfiMgoIPlyRi6kxa... > > What is the default priority? > A task posted to TaskScheduler without an explicit priority inherits its > priority from the calling context (e.g. a task posted to TaskScheduler > from a BACKGROUND task without an explicit .WithPriority() will have a > BACKGROUND priority). > > What is the default shutdown behavior? > It is not documented on purpose. If your task shouldn't be skipped on shutdown > (e.g. a task that persists user data on disk), it should have an explicit > BLOCK_SHUTDOWN shutdown behavior. If it's important not to wait on your task > on shutdown (e.g. it takes a long time to run and could cause a shutdown > hang), it should have an explicit CONTINUE_ON_SHUTDOWN shutdown behavior. ping
Sorry about the delay, but FWIW the ping is the first I saw of this review... https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... File chrome/browser/extensions/api/file_handlers/mime_util.cc (right): https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... chrome/browser/extensions/api/file_handlers/mime_util.cc:81: base::TaskPriority::BACKGROUND), I think the priority for all of these should be USER_BLOCKING. For example, these calls block the progress of opening files.
On 2017/02/14 06:03:21, benwells wrote: > Sorry about the delay, but FWIW the ping is the first I saw of this review... > > https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... > File chrome/browser/extensions/api/file_handlers/mime_util.cc (right): > > https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... > chrome/browser/extensions/api/file_handlers/mime_util.cc:81: > base::TaskPriority::BACKGROUND), > I think the priority for all of these should be USER_BLOCKING. For example, > these calls block the progress of opening files. GetMimeTypeForLocalPath() looks like a generic function that could used in various contexts. Instead of hard-coding a USER_BLOCKING priority, what do you think of posting tasks without an explicit .WithPriority() trait? As explained here https://cs.chromium.org/chromium/src/base/task_scheduler/post_task.h?q=post_t..., a task posted without an explicit .WithPriority() inherits its priority from the calling context.
On 2017/02/16 21:18:54, fdoray wrote: > On 2017/02/14 06:03:21, benwells wrote: > > Sorry about the delay, but FWIW the ping is the first I saw of this review... > > > > > https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... > > File chrome/browser/extensions/api/file_handlers/mime_util.cc (right): > > > > > https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... > > chrome/browser/extensions/api/file_handlers/mime_util.cc:81: > > base::TaskPriority::BACKGROUND), > > I think the priority for all of these should be USER_BLOCKING. For example, > > these calls block the progress of opening files. > > GetMimeTypeForLocalPath() looks like a generic function that could used in > various contexts. Instead of hard-coding a USER_BLOCKING priority, what do you > think of posting tasks without an explicit .WithPriority() trait? As explained > here > https://cs.chromium.org/chromium/src/base/task_scheduler/post_task.h?q=post_t..., > a task posted without an explicit .WithPriority() inherits its priority from the > calling context. That seems like the right thing to do. What priority will be inherited if the calling context hasn't been converted to this new system?
The CQ bit was checked by benwells@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/02/20 23:24:43, benwells wrote: > On 2017/02/16 21:18:54, fdoray wrote: > > On 2017/02/14 06:03:21, benwells wrote: > > > Sorry about the delay, but FWIW the ping is the first I saw of this > review... > > > > > > > > > https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... > > > File chrome/browser/extensions/api/file_handlers/mime_util.cc (right): > > > > > > > > > https://codereview.chromium.org/2675203004/diff/40001/chrome/browser/extensio... > > > chrome/browser/extensions/api/file_handlers/mime_util.cc:81: > > > base::TaskPriority::BACKGROUND), > > > I think the priority for all of these should be USER_BLOCKING. For example, > > > these calls block the progress of opening files. > > > > GetMimeTypeForLocalPath() looks like a generic function that could used in > > various contexts. Instead of hard-coding a USER_BLOCKING priority, what do you > > think of posting tasks without an explicit .WithPriority() trait? As explained > > here > > > https://cs.chromium.org/chromium/src/base/task_scheduler/post_task.h?q=post_t..., > > a task posted without an explicit .WithPriority() inherits its priority from > the > > calling context. > > That seems like the right thing to do. What priority will be inherited if the > calling context hasn't been converted to this new system? I saw the answer on another CL. This looks find but just sending through the CQ. BTW sorry about the delay, I took a long weekend for a camping trip..
lgtm
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
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": 60001, "attempt_start_ts": 1487687576413920, "parent_rev": "61a54d9b7c38464bb1d400a40fa34637cd20ed3f", "commit_rev": "147b9041c080e7620515541ca421cfc6426341e2"}
Message was sent while issue was closed.
Description was changed from ========== Use TaskScheduler instead of blocking pool in mime_util.cc. The blocking pool is being deprecated in favor of TaskScheduler. BUG=667892 R=benwells@chromium.org ========== to ========== Use TaskScheduler instead of blocking pool in mime_util.cc. The blocking pool is being deprecated in favor of TaskScheduler. BUG=667892 R=benwells@chromium.org Review-Url: https://codereview.chromium.org/2675203004 Cr-Commit-Position: refs/heads/master@{#451757} Committed: https://chromium.googlesource.com/chromium/src/+/147b9041c080e7620515541ca421... ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001) as https://chromium.googlesource.com/chromium/src/+/147b9041c080e7620515541ca421... |