Merge Blocking and Non-Blocking pools |
|||||
Issue descriptionAs explained in https://chromium-review.googlesource.com/c/chromium/src/+/1174380, V8 would like to turn tasks posted as MayBlock() into !MayBlock() after the fact. One way of doing this would be to let dynamic task traits[1] mutate all traits instead of just the priority for posted tasks. [1] https://docs.google.com/document/d/1SGy9VTXUwyXEX_yBZ0ukFAnS8B0hDeMUJD-1iALaE-Q/edit
Showing comments 34 - 133
of 133
Older ›
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e6c535318b1b73d37ed6b33d542111041d54b560 commit e6c535318b1b73d37ed6b33d542111041d54b560 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Aug 28 15:45:39 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/shell_integration_linux.cc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=thomasanderson@chromium.org Bug: 874080 Change-Id: I64920670d2ccb62299815969d324003f462d8ecd Reviewed-on: https://chromium-review.googlesource.com/1191801 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586720} [modify] https://crrev.com/e6c535318b1b73d37ed6b33d542111041d54b560/chrome/browser/shell_integration_linux.cc
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9983115b5c066addb668dea33bfe1a381c5f560c commit 9983115b5c066addb668dea33bfe1a381c5f560c Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Aug 28 17:29:47 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/component_updater. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=laforge@chromium.org Bug: 874080 Change-Id: If7aa633ca41f4bdf0836c2b25977b3cc0df9607a Reviewed-on: https://chromium-review.googlesource.com/1191100 Reviewed-by: Ryan Sleevi <rsleevi@chromium.org> Reviewed-by: Joshua Pawlicki <waffles@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586768} [modify] https://crrev.com/9983115b5c066addb668dea33bfe1a381c5f560c/chrome/browser/component_updater/crl_set_component_installer.cc
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ea160ec384b55573e9c319b837b3ea796fb78b54 commit ea160ec384b55573e9c319b837b3ea796fb78b54 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Aug 28 22:16:34 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/ui/settings. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=sczs@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I3da7acaa1d239af5fc937b7204aa649996555758 Reviewed-on: https://chromium-review.googlesource.com/1191196 Reviewed-by: Ioana Pandele <ioanap@chromium.org> Reviewed-by: Sergio Collazos <sczs@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586887} [modify] https://crrev.com/ea160ec384b55573e9c319b837b3ea796fb78b54/ios/chrome/browser/ui/settings/password_exporter.mm
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a2effa5b0149fa012c80de692cbc2a3f74793e22 commit a2effa5b0149fa012c80de692cbc2a3f74793e22 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Aug 28 22:26:28 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/conflicts. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=chrisha@chromium.org Bug: 874080 Change-Id: Ief95fc0cca793cd4c9863a6601a60b90499fd22f Reviewed-on: https://chromium-review.googlesource.com/1191800 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Chris Hamilton <chrisha@chromium.org> Cr-Commit-Position: refs/heads/master@{#586892} [modify] https://crrev.com/a2effa5b0149fa012c80de692cbc2a3f74793e22/chrome/browser/conflicts/enumerate_shell_extensions_win.cc [modify] https://crrev.com/a2effa5b0149fa012c80de692cbc2a3f74793e22/chrome/browser/conflicts/installed_applications_win.cc [modify] https://crrev.com/a2effa5b0149fa012c80de692cbc2a3f74793e22/chrome/browser/conflicts/msi_util_win.cc
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/47d86ab91833c73ccbef2e00e2e8b9b135cdbd63 commit 47d86ab91833c73ccbef2e00e2e8b9b135cdbd63 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Aug 28 22:37:41 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/ui/startup. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tmartino@chromium.org Bug: 874080 Change-Id: I2ffdda7281c765e991bc1666430cf6c433c7bc6c Reviewed-on: https://chromium-review.googlesource.com/1191676 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Tommy Martino <tmartino@chromium.org> Cr-Commit-Position: refs/heads/master@{#586896} [modify] https://crrev.com/47d86ab91833c73ccbef2e00e2e8b9b135cdbd63/chrome/browser/ui/startup/startup_browser_creator.cc
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/856bc58aefd887446b86ae6931f3be7a1578689b commit 856bc58aefd887446b86ae6931f3be7a1578689b Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Aug 28 23:28:40 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /base/nix. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=thomasanderson@chromium.org Bug: 874080 Change-Id: I4eb9b7f2a656a1cedac060787a52f39f2ce83688 Reviewed-on: https://chromium-review.googlesource.com/1194104 Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#586927} [modify] https://crrev.com/856bc58aefd887446b86ae6931f3be7a1578689b/base/nix/mime_util_xdg.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/14f009616733d0479b418e937aa50be17c15ad1a commit 14f009616733d0479b418e937aa50be17c15ad1a Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 14:37:46 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/metrics. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=rkaplow@chromium.org Bug: 874080 Change-Id: I002dbf2568e14095e79910d01499623fa2414976 Reviewed-on: https://chromium-review.googlesource.com/1191229 Reviewed-by: Robert Kaplow (slow) <rkaplow@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587108} [modify] https://crrev.com/14f009616733d0479b418e937aa50be17c15ad1a/chrome/browser/metrics/antivirus_metrics_provider_win.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2a877c3778d5c9a9f7c015a0221bf39a2a657a76 commit 2a877c3778d5c9a9f7c015a0221bf39a2a657a76 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 14:44:11 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/crash/content/browser/crash_dump_manager_android.cc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=isherman@chromium.org Bug: 874080 Change-Id: I45cbb6abf8867f25180b5837640cb3aec0c9d389 Reviewed-on: https://chromium-review.googlesource.com/1191140 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Ilya Sherman <isherman@chromium.org> Cr-Commit-Position: refs/heads/master@{#587110} [modify] https://crrev.com/2a877c3778d5c9a9f7c015a0221bf39a2a657a76/components/crash/content/browser/crash_dump_manager_android.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b66dce8ae78bb03069dd63a1a3d35025d3b2bf5a commit b66dce8ae78bb03069dd63a1a3d35025d3b2bf5a Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 14:46:34 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /content/browser/cocoa/system_hotkey_helper_mac.mm. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tapted@chromium.org Bug: 874080 Change-Id: I43d6fa7e8f26aea2cfeab0d028ae423b9d31d3ed Reviewed-on: https://chromium-review.googlesource.com/1191679 Reviewed-by: Trent Apted <tapted@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587112} [modify] https://crrev.com/b66dce8ae78bb03069dd63a1a3d35025d3b2bf5a/content/browser/cocoa/system_hotkey_helper_mac.mm
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8a52e18ec444e92e6b7817605a88d19cac14ca32 commit 8a52e18ec444e92e6b7817605a88d19cac14ca32 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 14:48:44 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /content/browser/web_contents/web_contents_android.cc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tedchoc@chromium.org Bug: 874080 Change-Id: I83ad9ab928cecc0e1442f76f6036e185d1d5f29a Reviewed-on: https://chromium-review.googlesource.com/1191785 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Ted Choc <tedchoc@chromium.org> Cr-Commit-Position: refs/heads/master@{#587113} [modify] https://crrev.com/8a52e18ec444e92e6b7817605a88d19cac14ca32/content/browser/web_contents/web_contents_android.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ef1da7a0191a3a3700060e3d2e019ac44c0598be commit ef1da7a0191a3a3700060e3d2e019ac44c0598be Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 14:58:35 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /base/win. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=grt@chromium.org Bug: 874080 Change-Id: I0fa6e881ea4b00d0c31b3c8026e095950764a627 Reviewed-on: https://chromium-review.googlesource.com/1191101 Reviewed-by: Greg Thompson <grt@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587117} [modify] https://crrev.com/ef1da7a0191a3a3700060e3d2e019ac44c0598be/base/win/shortcut.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c688eca1505303e66008dc4ae9d634ef5c0725fd commit c688eca1505303e66008dc4ae9d634ef5c0725fd Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 18:42:51 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/safe_browsing. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=vakh@chromium.org Bug: 874080 Change-Id: I49c31da1c962eb6005ed6655e259ed719c6f9953 Reviewed-on: https://chromium-review.googlesource.com/1190929 Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Jialiu Lin <jialiul@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587216} [modify] https://crrev.com/c688eca1505303e66008dc4ae9d634ef5c0725fd/chrome/browser/safe_browsing/download_protection/disk_image_type_sniffer_mac.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7d835e1250b54a8e9043b1c3a19ddd3351a04cf3 commit 7d835e1250b54a8e9043b1c3a19ddd3351a04cf3 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 19:00:09 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/ui/webui. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=scottchen@chromium.org Bug: 874080 Change-Id: If28d24f284744bcdda4b48c27d20952d17c20db2 Reviewed-on: https://chromium-review.googlesource.com/1191419 Reviewed-by: Tommy Li <tommycli@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587225} [modify] https://crrev.com/7d835e1250b54a8e9043b1c3a19ddd3351a04cf3/chrome/browser/ui/webui/about_ui.cc [modify] https://crrev.com/7d835e1250b54a8e9043b1c3a19ddd3351a04cf3/chrome/browser/ui/webui/settings_utils_linux.cc [modify] https://crrev.com/7d835e1250b54a8e9043b1c3a19ddd3351a04cf3/chrome/browser/ui/webui/version_handler.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/87eb1e9b74df4f1063c8726b36ae813c34b7c426 commit 87eb1e9b74df4f1063c8726b36ae813c34b7c426 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 19:54:11 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/profile_resetter. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=engedy@chromium.org Bug: 874080 Change-Id: Ib5ad110d3469e8813b0df121d88cfe2170de26ac Reviewed-on: https://chromium-review.googlesource.com/1191131 Reviewed-by: Balazs Engedy <engedy@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587258} [modify] https://crrev.com/87eb1e9b74df4f1063c8726b36ae813c34b7c426/chrome/browser/profile_resetter/profile_resetter.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/940b87bb7cb870e5d4415e238e192651a093db05 commit 940b87bb7cb870e5d4415e238e192651a093db05 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Aug 29 20:46:40 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/spellchecker. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=rouslan@chromium.org Bug: 874080 Change-Id: I82ae2e1ea937cce2e4bc815ac66f236081b82960 Reviewed-on: https://chromium-review.googlesource.com/1191531 Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587290} [modify] https://crrev.com/940b87bb7cb870e5d4415e238e192651a093db05/chrome/browser/spellchecker/spellcheck_custom_dictionary.cc [modify] https://crrev.com/940b87bb7cb870e5d4415e238e192651a093db05/chrome/browser/spellchecker/spellcheck_hunspell_dictionary.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a3104df1481fee9d1af2240401ea7dcade874bbc commit a3104df1481fee9d1af2240401ea7dcade874bbc Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 13:45:25 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/ui. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=marq@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I519b492dc31621ebc2f85fb7952a48e286e21d9f Reviewed-on: https://chromium-review.googlesource.com/1191532 Reviewed-by: Mark Cogan <marq@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587550} [modify] https://crrev.com/a3104df1481fee9d1af2240401ea7dcade874bbc/ios/chrome/browser/ui/external_file_controller.mm [modify] https://crrev.com/a3104df1481fee9d1af2240401ea7dcade874bbc/ios/chrome/browser/ui/open_in_controller.mm
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eb65c1f773b0957042ea38447af9236dc8a4e0ec commit eb65c1f773b0957042ea38447af9236dc8a4e0ec Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 13:46:23 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/sync_file_system. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tzik@chromium.org Bug: 874080 Change-Id: I12d0e731ef9d052129bec273df61cf1ccd670568 Reviewed-on: https://chromium-review.googlesource.com/1191194 Reviewed-by: Taiju Tsuiki <tzik@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587551} [modify] https://crrev.com/eb65c1f773b0957042ea38447af9236dc8a4e0ec/chrome/browser/sync_file_system/drive_backend/drive_backend_util.cc [modify] https://crrev.com/eb65c1f773b0957042ea38447af9236dc8a4e0ec/chrome/browser/sync_file_system/drive_backend/metadata_database.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/82ccaae04d3698d4c423dc152fb4a16305e11a45 commit 82ccaae04d3698d4c423dc152fb4a16305e11a45 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 14:09:59 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/media_galleries/fileapi. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tzik@chromium.org Bug: 874080 Change-Id: Ia1551113275376856e8d0492acf7ba359a548daf Reviewed-on: https://chromium-review.googlesource.com/1191132 Reviewed-by: Taiju Tsuiki <tzik@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587557} [modify] https://crrev.com/82ccaae04d3698d4c423dc152fb4a16305e11a45/chrome/browser/media_galleries/fileapi/av_scanning_file_validator.cc [modify] https://crrev.com/82ccaae04d3698d4c423dc152fb4a16305e11a45/chrome/browser/media_galleries/fileapi/supported_audio_video_checker.cc [modify] https://crrev.com/82ccaae04d3698d4c423dc152fb4a16305e11a45/chrome/browser/media_galleries/fileapi/supported_image_type_validator.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0d7b63e417cbc6a7b18d40a6aa5721da5feacc09 commit 0d7b63e417cbc6a7b18d40a6aa5721da5feacc09 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 14:27:22 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/app. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=marq@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I36b97957e5ad5b73a677a5fc17324c39e5901114 Reviewed-on: https://chromium-review.googlesource.com/1191793 Reviewed-by: Mark Cogan <marq@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587562} [modify] https://crrev.com/0d7b63e417cbc6a7b18d40a6aa5721da5feacc09/ios/chrome/app/memory_monitor.mm
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3f950e31311f425685f3f5149d9d0b95920bafff commit 3f950e31311f425685f3f5149d9d0b95920bafff Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 14:37:24 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/signin. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=droger@chromium.org Bug: 874080 Change-Id: I8299421165b4f9be1a6f45c8ba4e013853468073 Reviewed-on: https://chromium-review.googlesource.com/1191097 Reviewed-by: David Roger <droger@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587568} [modify] https://crrev.com/3f950e31311f425685f3f5149d9d0b95920bafff/components/signin/core/browser/account_tracker_service.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8598f5a4f7604888482530f3a2da093ec8eaaba0 commit 8598f5a4f7604888482530f3a2da093ec8eaaba0 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 16:18:13 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/android/shortcut_helper.cc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dominickn@chromium.org Bug: 874080 Change-Id: I4555e73ef3bfcb18745bb578d495198908c88609 Reviewed-on: https://chromium-review.googlesource.com/1191789 Reviewed-by: Dominick Ng <dominickn@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587609} [modify] https://crrev.com/8598f5a4f7604888482530f3a2da093ec8eaaba0/chrome/browser/android/shortcut_helper.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/08ccbf3633fa793c3def85b9fa4d4df790e18d9d commit 08ccbf3633fa793c3def85b9fa4d4df790e18d9d Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 16:31:26 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/browser_state. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=sdefresne@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I84da700fb1fc68393c2f5483c96895e8cc6b4d63 Reviewed-on: https://chromium-review.googlesource.com/1191141 Reviewed-by: Sylvain Defresne <sdefresne@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587619} [modify] https://crrev.com/08ccbf3633fa793c3def85b9fa4d4df790e18d9d/ios/chrome/browser/browser_state/chrome_browser_state_manager_impl.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b774142be2cc1d6087b889d19f6f0e9f482d1c3b commit b774142be2cc1d6087b889d19f6f0e9f482d1c3b Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 18:25:36 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chromeos/printing. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=thestig@chromium.org Bug: 874080 Change-Id: Ic3048f1874bd6d575a061c5f9f773df4850d6d32 Reviewed-on: https://chromium-review.googlesource.com/1191099 Reviewed-by: Sean Kau <skau@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587670} [modify] https://crrev.com/b774142be2cc1d6087b889d19f6f0e9f482d1c3b/chromeos/printing/ppd_cache.cc [modify] https://crrev.com/b774142be2cc1d6087b889d19f6f0e9f482d1c3b/chromeos/printing/ppd_provider.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1fe790f71b1514389913d5fb4fe8310b66025000 commit 1fe790f71b1514389913d5fb4fe8310b66025000 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 18:57:15 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/snapshots. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=justincohen@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I5df9b85d1914370ea2ada752c18bc5861f1591fc Reviewed-on: https://chromium-review.googlesource.com/1191408 Reviewed-by: Justin Cohen <justincohen@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587682} [modify] https://crrev.com/1fe790f71b1514389913d5fb4fe8310b66025000/ios/chrome/browser/snapshots/snapshot_cache.mm [modify] https://crrev.com/1fe790f71b1514389913d5fb4fe8310b66025000/ios/chrome/browser/snapshots/snapshots_util.mm
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/146f618a15dd0111074f181d791ee1363a88569c commit 146f618a15dd0111074f181d791ee1363a88569c Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 18:58:59 2018 Remove unnecessary AssertBlockingAllowed() in /extensions/browser/api/system_storage. Original CL intention was: This CL uses ScopedBlockingCall to mark blocking calls in /extensions/browser/api/system_storage. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=ningxin.hu@intel.com Bug: 874080 Change-Id: Ia8cf19506aa212d07e8dad54a07940f6e878799c Reviewed-on: https://chromium-review.googlesource.com/1191195 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#587683} [modify] https://crrev.com/146f618a15dd0111074f181d791ee1363a88569c/extensions/browser/api/system_storage/storage_info_provider.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a1f5a7aabdfe2fbc3f93f2d9cbd158a12c548c0f commit a1f5a7aabdfe2fbc3f93f2d9cbd158a12c548c0f Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 18:59:12 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/web_applications. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dominickn@chromium.org Bug: 874080 Change-Id: I82b1024084057eebf5425a8e42c5ee6b677f6b46 Reviewed-on: https://chromium-review.googlesource.com/1191788 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Cr-Commit-Position: refs/heads/master@{#587684} [modify] https://crrev.com/a1f5a7aabdfe2fbc3f93f2d9cbd158a12c548c0f/chrome/browser/web_applications/bookmark_apps/external_web_apps.cc [modify] https://crrev.com/a1f5a7aabdfe2fbc3f93f2d9cbd158a12c548c0f/chrome/browser/web_applications/components/web_app_shortcut_linux.cc [modify] https://crrev.com/a1f5a7aabdfe2fbc3f93f2d9cbd158a12c548c0f/chrome/browser/web_applications/components/web_app_shortcut_win.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0064f414429476906e2bf268424af45f1d57efd4 commit 0064f414429476906e2bf268424af45f1d57efd4 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 20:09:43 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/printing/cloud_print. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=thestig@chromium.org Bug: 874080 Change-Id: I6aea7df223626bd1ad2a2e6659a19920fd90cb2b Reviewed-on: https://chromium-review.googlesource.com/1191226 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587723} [modify] https://crrev.com/0064f414429476906e2bf268424af45f1d57efd4/chrome/browser/printing/cloud_print/privet_traffic_detector.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d1a600a111c4a35559641f4238f963d62bf0005d commit d1a600a111c4a35559641f4238f963d62bf0005d Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Aug 30 20:15:11 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/ui/ntp. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=justincohen@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I5e564d5d5fe57d7c17d06d6e3e79a1b1f609054d Reviewed-on: https://chromium-review.googlesource.com/1191677 Reviewed-by: Justin Cohen <justincohen@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#587732} [modify] https://crrev.com/d1a600a111c4a35559641f4238f963d62bf0005d/ios/chrome/browser/ui/ntp/ntp_tile_saver.mm
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bc09ae586edcaaf785391d786800647a01c0277a commit bc09ae586edcaaf785391d786800647a01c0277a Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Aug 31 08:58:55 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/reading_list. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=olivierrobin@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: If8096b4000f68e37625258c026af2db5f2b94a29 Reviewed-on: https://chromium-review.googlesource.com/1191787 Reviewed-by: Justin Cohen <justincohen@chromium.org> Reviewed-by: Olivier Robin <olivierrobin@chromium.org> Commit-Queue: Olivier Robin <olivierrobin@chromium.org> Cr-Commit-Position: refs/heads/master@{#587972} [modify] https://crrev.com/bc09ae586edcaaf785391d786800647a01c0277a/ios/chrome/browser/reading_list/reading_list_download_service.cc [modify] https://crrev.com/bc09ae586edcaaf785391d786800647a01c0277a/ios/chrome/browser/reading_list/url_downloader.cc
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6d6071c481db9e30b456bb1602ddf160eeffc0c2 commit 6d6071c481db9e30b456bb1602ddf160eeffc0c2 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Aug 31 14:39:09 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/share_extension. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=gambard@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: I346d55b3d32ce570cbff62031d82a5888c3c7372 Reviewed-on: https://chromium-review.googlesource.com/1191530 Reviewed-by: Olivier Robin <olivierrobin@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588020} [modify] https://crrev.com/6d6071c481db9e30b456bb1602ddf160eeffc0c2/ios/chrome/browser/share_extension/share_extension_item_receiver.mm
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5c14fd253569db8a327f068089c4170321700e25 commit 5c14fd253569db8a327f068089c4170321700e25 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Aug 31 15:09:26 2018 [TaskScheduler]: Update doc for assertBlockingAllowed(). Using ScopedBlockingCall is preferred to assertBlockingAllowed as it also serves as annotation. This CL updates documentation on assertBlockingAllowed() to describe that. TBR=gab@chromium.org Bug: 874080 Change-Id: I1e5b8e85c2defb9a87e2b1784f2ea86cb69019c1 Reviewed-on: https://chromium-review.googlesource.com/1197286 Reviewed-by: François Doray <fdoray@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588025} [modify] https://crrev.com/5c14fd253569db8a327f068089c4170321700e25/base/threading/thread_restrictions.h
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/53aab5cbe2160325cf59647b320fa07aa9558c31 commit 53aab5cbe2160325cf59647b320fa07aa9558c31 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Aug 31 15:27:11 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/arc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=hidehiko@chromium.org Bug: 874080 Change-Id: Ia1f51ac98e70110b6c405a8a56e792b6a0ff1aca Reviewed-on: https://chromium-review.googlesource.com/1190928 Reviewed-by: Hidehiko Abe <hidehiko@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588027} [modify] https://crrev.com/53aab5cbe2160325cf59647b320fa07aa9558c31/components/arc/arc_features_parser.cc
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/35ffb73588dcd752d299e43361b5ac9ea527a26a commit 35ffb73588dcd752d299e43361b5ac9ea527a26a Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Aug 31 15:47:48 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/profiles. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=mmenke@chromium.org Bug: 874080 Change-Id: I21475ba8f80e505e7310d6b6689cc2a40f047583 Reviewed-on: https://chromium-review.googlesource.com/1191798 Reviewed-by: Bernhard Bauer <bauerb@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588033} [modify] https://crrev.com/35ffb73588dcd752d299e43361b5ac9ea527a26a/chrome/browser/profiles/profile_attributes_storage.cc [modify] https://crrev.com/35ffb73588dcd752d299e43361b5ac9ea527a26a/chrome/browser/profiles/profile_impl.cc [modify] https://crrev.com/35ffb73588dcd752d299e43361b5ac9ea527a26a/chrome/browser/profiles/profile_info_cache.cc [modify] https://crrev.com/35ffb73588dcd752d299e43361b5ac9ea527a26a/chrome/browser/profiles/profile_manager.cc [modify] https://crrev.com/35ffb73588dcd752d299e43361b5ac9ea527a26a/chrome/browser/profiles/profile_shortcut_manager_win.cc
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8c93e4bf348b44b8e3824f7392efc0ddfc41fe44 commit 8c93e4bf348b44b8e3824f7392efc0ddfc41fe44 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Aug 31 16:36:57 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /extensions/browser/api/file_handlers. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=benwells@chromium.org Bug: 874080 Change-Id: Ic7d3365b90abda07a86684352e24cd359aebdfb7 Reviewed-on: https://chromium-review.googlesource.com/1191138 Reviewed-by: Ben Wells <benwells@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588056} [modify] https://crrev.com/8c93e4bf348b44b8e3824f7392efc0ddfc41fe44/extensions/browser/api/file_handlers/app_file_handler_util.cc
,
Sep 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/438ff1e21d1727b856dc69065c78dfb7c660d844 commit 438ff1e21d1727b856dc69065c78dfb7c660d844 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 04 16:28:26 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/download. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dtrainor@chromium.org Bug: 874080 Change-Id: Ifc38a9f45d9812801b6aeae6d89830c0e9377a9b Reviewed-on: https://chromium-review.googlesource.com/1191797 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: David Trainor <dtrainor@chromium.org> Cr-Commit-Position: refs/heads/master@{#588535} [modify] https://crrev.com/438ff1e21d1727b856dc69065c78dfb7c660d844/chrome/browser/download/download_commands.cc [modify] https://crrev.com/438ff1e21d1727b856dc69065c78dfb7c660d844/chrome/browser/download/image_thumbnail_request.cc
,
Sep 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/438ff1e21d1727b856dc69065c78dfb7c660d844 commit 438ff1e21d1727b856dc69065c78dfb7c660d844 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 04 16:28:26 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/download. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dtrainor@chromium.org Bug: 874080 Change-Id: Ifc38a9f45d9812801b6aeae6d89830c0e9377a9b Reviewed-on: https://chromium-review.googlesource.com/1191797 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: David Trainor <dtrainor@chromium.org> Cr-Commit-Position: refs/heads/master@{#588535} [modify] https://crrev.com/438ff1e21d1727b856dc69065c78dfb7c660d844/chrome/browser/download/download_commands.cc [modify] https://crrev.com/438ff1e21d1727b856dc69065c78dfb7c660d844/chrome/browser/download/image_thumbnail_request.cc
,
Sep 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a52089cd0dd9b3948089a7a302de9e3b1cd246e4 commit a52089cd0dd9b3948089a7a302de9e3b1cd246e4 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Sep 05 17:21:52 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/ui/ash. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=derat@chromium.org Bug: 874080 Change-Id: I478ab0929c7bba7131b214205041e66bb23de087 Reviewed-on: https://chromium-review.googlesource.com/1191182 Reviewed-by: Dan Erat <derat@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588909} [modify] https://crrev.com/a52089cd0dd9b3948089a7a302de9e3b1cd246e4/chrome/browser/ui/ash/chrome_screenshot_grabber.cc
,
Sep 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0eaa131f244ce777fb5808d5f29c2a61ac965014 commit 0eaa131f244ce777fb5808d5f29c2a61ac965014 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Sep 05 17:43:01 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/safe_browsing/chrome_cleaner. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=csharp@chromium.org Bug: 874080 Change-Id: I131400a7be516f5ea30857e04528550ea5472fae Reviewed-on: https://chromium-review.googlesource.com/1191230 Reviewed-by: Chris Sharp <csharp@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#588922} [modify] https://crrev.com/0eaa131f244ce777fb5808d5f29c2a61ac965014/chrome/browser/safe_browsing/chrome_cleaner/chrome_cleaner_controller_impl_win.cc
,
Sep 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/616d2ac872c5492942cf65ec67b4b39d32200d4e commit 616d2ac872c5492942cf65ec67b4b39d32200d4e Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 06 18:54:21 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/printing. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dpapad@chromium.org Bug: 874080 Change-Id: If905506e78f47d3a2524a4d574184def19f3ce54 Reviewed-on: https://chromium-review.googlesource.com/1191786 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#589220} [modify] https://crrev.com/616d2ac872c5492942cf65ec67b4b39d32200d4e/components/printing/common/printer_capabilities.cc
,
Sep 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/889b47797e537c5eb0c55b5369d48277c113660f commit 889b47797e537c5eb0c55b5369d48277c113660f Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 06 18:56:29 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/printing. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dpapad@chromium.org Bug: 874080 Change-Id: I23d9583ee267f5d88fb8c2e708fd7055d9f05951 Reviewed-on: https://chromium-review.googlesource.com/1191184 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#589223} [modify] https://crrev.com/889b47797e537c5eb0c55b5369d48277c113660f/chrome/browser/printing/printer_manager_dialog_linux.cc
,
Sep 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3caed7f82e26ee201c377f7c5b41efa422e4f769 commit 3caed7f82e26ee201c377f7c5b41efa422e4f769 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 06 18:57:32 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/chromeos. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=satorux@chromium.org Bug: 874080 Change-Id: Ic87ecc4c25a20a2dea3053249c03dafded46db27 Reviewed-on: https://chromium-review.googlesource.com/1191236 Reviewed-by: Satoru Takabayashi <satorux@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#589225} [modify] https://crrev.com/3caed7f82e26ee201c377f7c5b41efa422e4f769/chrome/browser/chromeos/app_mode/kiosk_app_data_base.cc [modify] https://crrev.com/3caed7f82e26ee201c377f7c5b41efa422e4f769/chrome/browser/chromeos/customization/customization_document.cc [modify] https://crrev.com/3caed7f82e26ee201c377f7c5b41efa422e4f769/chrome/browser/chromeos/mobile/mobile_activator.cc [modify] https://crrev.com/3caed7f82e26ee201c377f7c5b41efa422e4f769/chrome/browser/chromeos/mobile_config.cc [modify] https://crrev.com/3caed7f82e26ee201c377f7c5b41efa422e4f769/chrome/browser/chromeos/power/process_data_collector.cc [modify] https://crrev.com/3caed7f82e26ee201c377f7c5b41efa422e4f769/chrome/browser/chromeos/system/automatic_reboot_manager.cc
,
Sep 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0310e5c9e334c50eeea457d6901d8f5af492b59c commit 0310e5c9e334c50eeea457d6901d8f5af492b59c Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 06 18:57:35 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/upgrade_detector. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=grt@chromium.org Bug: 874080 Change-Id: I902becb0feb9bf1e0464c2dd507b734fb5e16508 Reviewed-on: https://chromium-review.googlesource.com/1190932 Reviewed-by: Greg Thompson <grt@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#589226} [modify] https://crrev.com/0310e5c9e334c50eeea457d6901d8f5af492b59c/chrome/browser/upgrade_detector/upgrade_detector_impl.cc
,
Sep 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7675ee5123f77abfc82d7cab8fa800afc5d3e0f0 commit 7675ee5123f77abfc82d7cab8fa800afc5d3e0f0 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 11 21:55:46 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/memory_details_android.cc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dtrainor@chromium.org Bug: 874080 Change-Id: I26104d2e0bc7817b955152a60a8ee4c97b033079 Reviewed-on: https://chromium-review.googlesource.com/1191418 Reviewed-by: David Trainor <dtrainor@chromium.org> Reviewed-by: Siddhartha S <ssid@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#590497} [modify] https://crrev.com/7675ee5123f77abfc82d7cab8fa800afc5d3e0f0/chrome/browser/memory_details_android.cc
,
Sep 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d120ebf179cc5e18aea78f74d1493d07c78af83f commit d120ebf179cc5e18aea78f74d1493d07c78af83f Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Sep 14 23:38:21 2018 [TaskScheduler]: Save last error in ScopedBlockingCall Tls affects result of GetLastError on windows. To avoid interaction with base::File, last error is saved and restored in the destructor of ScopedBlockingCall. Bug: 874080 Change-Id: Id17ac4e7ee4ffaf33eda30784b86ad41e21b8b96 Reviewed-on: https://chromium-review.googlesource.com/1220172 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Reviewed-by: François Doray <fdoray@chromium.org> Cr-Commit-Position: refs/heads/master@{#591525} [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/BUILD.gn [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/allocator/allocator_interception_mac.mm [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/logging.cc [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/logging.h [delete] https://crrev.com/eeeaae5da37b46987963460e4bb58828018efbe2/base/scoped_clear_errno.h [delete] https://crrev.com/eeeaae5da37b46987963460e4bb58828018efbe2/base/scoped_clear_errno_unittest.cc [add] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/scoped_clear_last_error.h [add] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/scoped_clear_last_error_unittest.cc [add] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/scoped_clear_last_error_win.cc [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/strings/string_number_conversions.cc [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/strings/stringprintf.cc [modify] https://crrev.com/d120ebf179cc5e18aea78f74d1493d07c78af83f/base/threading/scoped_blocking_call.cc
,
Sep 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3879b05ea9bf27d227f4678e190f682a7c8d647f commit 3879b05ea9bf27d227f4678e190f682a7c8d647f Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Sep 17 14:17:22 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /base. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=danakj@chromium.org Bug: 874080 Change-Id: I64c1a2779933e60380c03a8ba0185a9564350c2f Reviewed-on: https://chromium-review.googlesource.com/1191231 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Albert J. Wong <ajwong@chromium.org> Cr-Commit-Position: refs/heads/master@{#591664} [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/file_version_info_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_enumerator_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_enumerator_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_util_mac.mm [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_util_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_util_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/file_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/memory_mapped_file_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/files/memory_mapped_file_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/native_library_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/native_library_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/observer_list_threadsafe_unittest.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/process/launch_mac.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/process/launch_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/sync_socket_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/sync_socket_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/sys_info_posix.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/sys_info_win.cc [modify] https://crrev.com/3879b05ea9bf27d227f4678e190f682a7c8d647f/base/threading/platform_thread_posix.cc
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e2181f8270226027f905c30fd7f6d62af03eb3e8 commit e2181f8270226027f905c30fd7f6d62af03eb3e8 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Tue Sep 18 19:48:54 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/sync. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tschumann@chromium.org Bug: 874080 Change-Id: I291ccbeca7b5115053ad57bb3ba072eaad10172f Reviewed-on: https://chromium-review.googlesource.com/1194103 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Tim Schumann <tschumann@chromium.org> Cr-Commit-Position: refs/heads/master@{#592155} [modify] https://crrev.com/e2181f8270226027f905c30fd7f6d62af03eb3e8/components/sync/base/get_session_name.cc
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f8978453fd33fdfbf9de40ff7a32aaef2b37031d commit f8978453fd33fdfbf9de40ff7a32aaef2b37031d Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 18 21:06:34 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/devtools. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=caseq@chromium.org Bug: 874080 Change-Id: I09d16aad817f3f9cc756d32f93a0c589c8d52782 Reviewed-on: https://chromium-review.googlesource.com/1191812 Reviewed-by: Andrey Kosyakov <caseq@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#592188} [modify] https://crrev.com/f8978453fd33fdfbf9de40ff7a32aaef2b37031d/chrome/browser/devtools/devtools_file_helper.cc
,
Sep 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/83dab8d0d4329ee563447d4294d00a2d987fc54c commit 83dab8d0d4329ee563447d4294d00a2d987fc54c Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 18 23:26:21 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /content/browser/devtools. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=caseq@chromium.org Bug: 874080 Change-Id: Ib5b94340df750c17a0a3ab0b8dd76f4fc70c5c5e Reviewed-on: https://chromium-review.googlesource.com/1191678 Reviewed-by: Andrey Kosyakov <caseq@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#592254} [modify] https://crrev.com/83dab8d0d4329ee563447d4294d00a2d987fc54c/content/browser/devtools/devtools_stream_file.cc [modify] https://crrev.com/83dab8d0d4329ee563447d4294d00a2d987fc54c/content/browser/devtools/protocol/devtools_download_manager_delegate.cc
,
Sep 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f72fdc9b1df0352c4039dac8068dcbb4cab94839 commit f72fdc9b1df0352c4039dac8068dcbb4cab94839 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Sep 19 17:02:31 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /device/bluetooth. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=ortuno@chromium.org Bug: 874080 Change-Id: Ib9d437546b43da34663eb96562becc94d6655989 Reviewed-on: https://chromium-review.googlesource.com/1191795 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#592445} [modify] https://crrev.com/f72fdc9b1df0352c4039dac8068dcbb4cab94839/device/bluetooth/bluetooth_init_win.cc [modify] https://crrev.com/f72fdc9b1df0352c4039dac8068dcbb4cab94839/device/bluetooth/bluetooth_socket_net.cc [modify] https://crrev.com/f72fdc9b1df0352c4039dac8068dcbb4cab94839/device/bluetooth/bluetooth_socket_win.cc
,
Sep 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/41f33787eac2d117cc453a637fc94e0c4a376d6b commit 41f33787eac2d117cc453a637fc94e0c4a376d6b Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Thu Sep 20 14:01:44 2018 Remove chromeos/binder/ directory since it's unused. Original CL intention was: This CL uses ScopedBlockingCall to mark blocking calls in /chromeos/binder. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=satorux@chromium.org Bug: 874080 Change-Id: Ia8c04385530dbaefee972c8ebffc46c1ec627aa3 Reviewed-on: https://chromium-review.googlesource.com/1191246 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org> Cr-Commit-Position: refs/heads/master@{#592786} [modify] https://crrev.com/41f33787eac2d117cc453a637fc94e0c4a376d6b/chromeos/BUILD.gn [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/DEPS [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/OWNERS [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/binder_driver_api.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/buffer_reader.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/buffer_reader.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/buffer_reader_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/command_broker.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/command_broker.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/command_broker_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/command_stream.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/command_stream.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/command_stream_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/constants.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/driver.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/driver.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/driver_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/end_to_end_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/ipc_thread.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/ipc_thread.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/local_object.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/local_object.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/object.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/remote_object.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/remote_object.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/service_manager_proxy.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/service_manager_proxy.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/service_manager_proxy_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/status.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/test_service.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/test_service.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_data.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_data_from_driver.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_data_from_driver.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_data_read_write_unittest.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_data_reader.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_data_reader.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_status.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/transaction_status.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/util.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/util.h [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/writable_transaction_data.cc [delete] https://crrev.com/03c1a559253973aba98f15200f4ed08366c7c80d/chromeos/binder/writable_transaction_data.h
,
Sep 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/749270b6c346b55c0be82dd626d07e52664acf11 commit 749270b6c346b55c0be82dd626d07e52664acf11 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 20 14:47:12 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/media. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=chcunningham@chromium.org TBR=chcunningham@chromium.org Bug: 874080 Change-Id: If0029c7a63eb0cc35a18dbcec7c21cbdaeeaf156 Reviewed-on: https://chromium-review.googlesource.com/1191193 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Yuchen Liu <yucliu@chromium.org> Cr-Commit-Position: refs/heads/master@{#592799} [modify] https://crrev.com/749270b6c346b55c0be82dd626d07e52664acf11/chrome/browser/media/android/cdm/media_drm_license_manager.cc
,
Sep 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/df63a82ac993e212cf74f34355e04d9c8ede40b2 commit df63a82ac993e212cf74f34355e04d9c8ede40b2 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 20 17:55:00 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /gpu. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=piman@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I94991868b2383b0f5b359399ea97597518ebea7f Reviewed-on: https://chromium-review.googlesource.com/1191410 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#592866} [modify] https://crrev.com/df63a82ac993e212cf74f34355e04d9c8ede40b2/gpu/ipc/service/gpu_init.cc
,
Sep 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/226c6cce1d99eeb746a6a74bc9bbf062751f7bf7 commit 226c6cce1d99eeb746a6a74bc9bbf062751f7bf7 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 20 18:41:38 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /device. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=reillyg@chromium.org Bug: 874080 Change-Id: I1bad5e82040c40aa770c36d3825dfc14dd9aad0f Reviewed-on: https://chromium-review.googlesource.com/1191813 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#592887} [modify] https://crrev.com/226c6cce1d99eeb746a6a74bc9bbf062751f7bf7/device/base/device_monitor_linux.cc [modify] https://crrev.com/226c6cce1d99eeb746a6a74bc9bbf062751f7bf7/device/serial/serial_device_enumerator_linux.cc [modify] https://crrev.com/226c6cce1d99eeb746a6a74bc9bbf062751f7bf7/device/serial/serial_device_enumerator_mac.cc [modify] https://crrev.com/226c6cce1d99eeb746a6a74bc9bbf062751f7bf7/device/serial/serial_device_enumerator_win.cc
,
Sep 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7f1f6062eb0057191403b8c14062d6aff4729ea8 commit 7f1f6062eb0057191403b8c14062d6aff4729ea8 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Sep 21 14:41:43 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /dbus. This CL adds ScopedBlockingCall(MAY_BLOCK) for each scope containing a dbus_* call, assuming all of those calls may block. I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=satorux@chromium.org Bug: 874080 Change-Id: Ib90b59280bd22cb671a64bacabe299c02c6d6081 Reviewed-on: https://chromium-review.googlesource.com/1190930 Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#593177} [modify] https://crrev.com/7f1f6062eb0057191403b8c14062d6aff4729ea8/dbus/bus.cc [modify] https://crrev.com/7f1f6062eb0057191403b8c14062d6aff4729ea8/dbus/object_proxy.cc
,
Sep 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1da585964eba19534d11d00a1bf3be55b25b75e9 commit 1da585964eba19534d11d00a1bf3be55b25b75e9 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Sep 21 14:47:20 2018 [TaskScheduler]: Add ScopedBlockingCall in ReadFileToStringWithMaxSize. While OpenFile/CloseFile are already covered by ScopedBlockingCall, this function does file reading operations (fread), which may block. ScopedBlockingCall serves as a precise annotation of the scope that may/will block for the scheduler. Since it supports nesting, there is no problem calling CloseFile() in the same scope. Bug: 874080 Change-Id: Id65de018cc20a2788d42d408c1c49052eed813c0 Reviewed-on: https://chromium-review.googlesource.com/1236393 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#593180} [modify] https://crrev.com/1da585964eba19534d11d00a1bf3be55b25b75e9/base/files/file_util.cc
,
Sep 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7daf4834e7b87a4aa32becd8e2ca0da0ca2612a9 commit 7daf4834e7b87a4aa32becd8e2ca0da0ca2612a9 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Sep 21 17:06:38 2018 Remove unnecessary AssertBlockingAllowed() in /components/bookmarks. Original CL intention was: This CL uses ScopedBlockingCall to mark blocking calls in /components/bookmarks. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=sky@chromium.org Bug: 874080 Change-Id: I8ca5da34968b9b94659c189b02e982f51399ab49 Reviewed-on: https://chromium-review.googlesource.com/1191799 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#593237} [modify] https://crrev.com/7daf4834e7b87a4aa32becd8e2ca0da0ca2612a9/components/bookmarks/browser/bookmark_storage.cc
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/be53fc228d538ef12605a1f401f3fa44a4a3efa5 commit be53fc228d538ef12605a1f401f3fa44a4a3efa5 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Sep 24 19:38:47 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/extensions/api/storage. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=rdevlin.cronin@chromium.org Bug: 874080 Change-Id: I4de4dd7b51419500492ecce093c5e82cd9fe6b35 Reviewed-on: https://chromium-review.googlesource.com/1191809 Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#593637} [modify] https://crrev.com/be53fc228d538ef12605a1f401f3fa44a4a3efa5/chrome/browser/extensions/api/storage/managed_value_store_cache.cc
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9d234f0b3a909812bcdbe646e7b1b84015e48b1a commit 9d234f0b3a909812bcdbe646e7b1b84015e48b1a Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Sep 24 21:08:30 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/background/background_mode_manager_mac.mm. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=avi@chromium.org Bug: 874080 Change-Id: Ic807c6eb4e22dc7ebdd34e2240e1fe6484e44174 Reviewed-on: https://chromium-review.googlesource.com/1191232 Reviewed-by: Avi Drissman <avi@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#593676} [modify] https://crrev.com/9d234f0b3a909812bcdbe646e7b1b84015e48b1a/chrome/browser/background/background_mode_manager_mac.mm
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4f2e41beda87f7234d6e85aadf2c05f34613fca8 commit 4f2e41beda87f7234d6e85aadf2c05f34613fca8 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Sep 24 22:10:11 2018 [TaskScheduler]: Use AssertLongCPUWorkAllowed to better match intent in chrome/browser/android Instead of ScopedBlockingCall or AssertBlockingAllowed(), AssertLongCPUWorkAllowed is used in FinalizeLauncherIconInBackground() and in CreateLauncherIconFromFaviconInBackground(). Original CL intention was: This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/android/webapps. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=dominickn@chromium.org Bug: 874080 Change-Id: I31ed4164dbd93d424b7a3a69f833519d13c6fbf1 Reviewed-on: https://chromium-review.googlesource.com/1191185 Reviewed-by: Dominick Ng <dominickn@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#593708} [modify] https://crrev.com/4f2e41beda87f7234d6e85aadf2c05f34613fca8/chrome/browser/android/shortcut_helper.cc [modify] https://crrev.com/4f2e41beda87f7234d6e85aadf2c05f34613fca8/chrome/browser/android/webapps/add_to_homescreen_data_fetcher.cc
,
Sep 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4978325ba1e17f22613cdc51456771b2d051ed01 commit 4978325ba1e17f22613cdc51456771b2d051ed01 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Sep 24 23:23:07 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/win. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=gab@chromium.org Bug: 874080 Change-Id: Icf9c25f614e296b069ce76297ba85b3b8b6e1197 Reviewed-on: https://chromium-review.googlesource.com/1191663 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#593738} [modify] https://crrev.com/4978325ba1e17f22613cdc51456771b2d051ed01/chrome/browser/win/jumplist_file_util.cc
,
Sep 25
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d1e21471fe57fce68c1f3e94ce0f4bbb9bcf999d commit d1e21471fe57fce68c1f3e94ce0f4bbb9bcf999d Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 25 14:50:16 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/chromeos/arc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=yusukes@chromium.org Bug: 874080 Change-Id: I94e3d2a1094235c5b8d2fb3dbb52597df035bb18 Reviewed-on: https://chromium-review.googlesource.com/1191283 Reviewed-by: Yusuke Sato <yusukes@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#593929} [modify] https://crrev.com/d1e21471fe57fce68c1f3e94ce0f4bbb9bcf999d/chrome/browser/chromeos/arc/arc_util.cc [modify] https://crrev.com/d1e21471fe57fce68c1f3e94ce0f4bbb9bcf999d/chrome/browser/chromeos/arc/fileapi/arc_content_file_system_file_stream_reader.cc
,
Sep 25
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73e13c546b5d62ed9502a4b0de34974c4a2f0792 commit 73e13c546b5d62ed9502a4b0de34974c4a2f0792 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Tue Sep 25 16:04:19 2018 [TaskScheduler] Add documentation for ScopedBlockingCall. This CL defines "blocking call" in scoped_blocking_call.h and mentions that ScopedBlockingCall serves as annotation for the TaskScheduler. Bug: 874080 Change-Id: Id85a42eb4750620b26c587adf5a43f471ea1168c Reviewed-on: https://chromium-review.googlesource.com/1236459 Reviewed-by: François Doray <fdoray@chromium.org> Commit-Queue: François Doray <fdoray@chromium.org> Cr-Commit-Position: refs/heads/master@{#593956} [modify] https://crrev.com/73e13c546b5d62ed9502a4b0de34974c4a2f0792/base/threading/scoped_blocking_call.h
,
Sep 25
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/351114e148f723f9e24a162e1f28d53b76720577 commit 351114e148f723f9e24a162e1f28d53b76720577 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 25 19:02:42 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/media_galleries. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=reillyg@chromium.org Bug: 874080 Change-Id: I517572321e5fd315216e74d83ecf541a8fc57667 Reviewed-on: https://chromium-review.googlesource.com/1191415 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#594037} [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/chromeos/mtp_device_delegate_impl_chromeos.cc [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/chromeos/mtp_read_file_worker.cc [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/gallery_watch_manager.cc [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/win/mtp_device_delegate_impl_win.cc [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/win/mtp_device_object_enumerator.cc [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/win/mtp_device_operations_util.cc [modify] https://crrev.com/351114e148f723f9e24a162e1f28d53b76720577/chrome/browser/media_galleries/win/portable_device_map_service.cc
,
Sep 25
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/44ffdf49d5a0c6a99857bbe29cca68416ce7ac1e commit 44ffdf49d5a0c6a99857bbe29cca68416ce7ac1e Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Sep 25 23:15:10 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /device/usb. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=reillyg@chromium.org Bug: 874080 Change-Id: I0ee2ff9b2a81c101f943716b4965d4f21f231e41 Reviewed-on: https://chromium-review.googlesource.com/1191322 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#594140} [modify] https://crrev.com/44ffdf49d5a0c6a99857bbe29cca68416ce7ac1e/device/usb/usb_device_handle_usbfs.cc [modify] https://crrev.com/44ffdf49d5a0c6a99857bbe29cca68416ce7ac1e/device/usb/usb_device_impl.cc [modify] https://crrev.com/44ffdf49d5a0c6a99857bbe29cca68416ce7ac1e/device/usb/usb_service_linux.cc
,
Sep 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2d56a0399beef8bb465d17d5a0def7473382657b commit 2d56a0399beef8bb465d17d5a0def7473382657b Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 27 15:11:47 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/download. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=shaktisahu@chromium.org TBR=shaktisahu@chromium.org Bug: 874080 Change-Id: Icf3e527d0d344e099a9debe054a8046273baebef Reviewed-on: https://chromium-review.googlesource.com/1191096 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Xing Liu <xingliu@chromium.org> Cr-Commit-Position: refs/heads/master@{#594725} [modify] https://crrev.com/2d56a0399beef8bb465d17d5a0def7473382657b/components/download/internal/background_service/file_monitor_impl.cc [modify] https://crrev.com/2d56a0399beef8bb465d17d5a0def7473382657b/components/download/internal/common/base_file_win.cc [modify] https://crrev.com/2d56a0399beef8bb465d17d5a0def7473382657b/components/download/quarantine/quarantine_linux.cc [modify] https://crrev.com/2d56a0399beef8bb465d17d5a0def7473382657b/components/download/quarantine/quarantine_mac.mm [modify] https://crrev.com/2d56a0399beef8bb465d17d5a0def7473382657b/components/download/quarantine/quarantine_win.cc
,
Sep 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6fa6aa53099a0eb16abc8badda855b9461b755cb commit 6fa6aa53099a0eb16abc8badda855b9461b755cb Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 27 16:38:12 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/shell_integration_win.cc. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=gab@chromium.org Bug: 874080 Change-Id: Ifa0f35aa3000ab99401647c45a131b3c457eeb8c Reviewed-on: https://chromium-review.googlesource.com/1191095 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Patrick Monette <pmonette@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#594749} [modify] https://crrev.com/6fa6aa53099a0eb16abc8badda855b9461b755cb/chrome/browser/shell_integration_win.cc
,
Sep 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ef3cf29580bf5ea20c3f2556956a90793e1b6222 commit ef3cf29580bf5ea20c3f2556956a90793e1b6222 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 27 17:38:38 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/common/app_group. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=olivierrobin@chromium.org Bug: 874080 Change-Id: I74ae6a8f94ea54ee9738a67493dc545921dc99e9 Reviewed-on: https://chromium-review.googlesource.com/1191420 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Olivier Robin <olivierrobin@chromium.org> Cr-Commit-Position: refs/heads/master@{#594770} [modify] https://crrev.com/ef3cf29580bf5ea20c3f2556956a90793e1b6222/ios/chrome/common/app_group/app_group_metrics_mainapp.mm
,
Sep 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9fc69fb78026aa5b8ce86de34840feb46400c8e1 commit 9fc69fb78026aa5b8ce86de34840feb46400c8e1 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Sep 27 18:08:46 2018 [TaskScheduler]: Add ScopedBlockingCall in FilePathWatcher::Watch. ScopedBlockingCall serves as a precise annotation of the scope that may/will block for the scheduler. This CL moves ScopedBlockingCall from the call site to the implementation of FilePathWatcher::Watch, which is more accurate. Bug: 874080 Change-Id: I03cf5d28a2c4763c0c358699aff9f32d686b46b6 Reviewed-on: https://chromium-review.googlesource.com/1243366 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Lei Zhang <thestig@chromium.org> Reviewed-by: Reilly Grant <reillyg@chromium.org> Cr-Commit-Position: refs/heads/master@{#594782} [modify] https://crrev.com/9fc69fb78026aa5b8ce86de34840feb46400c8e1/base/files/file_path_watcher_fsevents.cc [modify] https://crrev.com/9fc69fb78026aa5b8ce86de34840feb46400c8e1/base/files/file_path_watcher_kqueue.cc [modify] https://crrev.com/9fc69fb78026aa5b8ce86de34840feb46400c8e1/base/files/file_path_watcher_linux.cc [modify] https://crrev.com/9fc69fb78026aa5b8ce86de34840feb46400c8e1/base/files/file_path_watcher_win.cc [modify] https://crrev.com/9fc69fb78026aa5b8ce86de34840feb46400c8e1/chrome/browser/media_galleries/gallery_watch_manager.cc
,
Sep 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1288d883b329ae3c4782fe5656fe1cb6144b6838 commit 1288d883b329ae3c4782fe5656fe1cb6144b6838 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Sep 28 14:37:49 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /device/bluetooth/bluez. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=rkc@chromium.org Bug: 874080 Change-Id: I4ab9d5ae6b94c448f3e30e6e9c607fb88a1078bf Reviewed-on: https://chromium-review.googlesource.com/1191183 Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#595086} [modify] https://crrev.com/1288d883b329ae3c4782fe5656fe1cb6144b6838/device/bluetooth/bluez/bluetooth_socket_bluez.cc
,
Oct 1
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b6ebcffbb09ced4d0a544b15e4e8dfc0c0414873 commit b6ebcffbb09ced4d0a544b15e4e8dfc0c0414873 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Oct 01 20:04:41 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=rohitrao@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs Change-Id: Id297ebc108dc8f8915402602ae12a63e5a3131d0 Reviewed-on: https://chromium-review.googlesource.com/1191186 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: David Roger <droger@chromium.org> Cr-Commit-Position: refs/heads/master@{#595530} [modify] https://crrev.com/b6ebcffbb09ced4d0a544b15e4e8dfc0c0414873/ios/chrome/browser/file_metadata_util.mm
,
Oct 1
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/31e4dccfb1777b8a6c31255872682d10bc32492c commit 31e4dccfb1777b8a6c31255872682d10bc32492c Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Oct 01 20:24:06 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chromecast/browser/metrics. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=bcwhite@chromium.org Bug: 874080 Change-Id: If065cdbaa716f646caa8c4258053a2f4a089bc21 Reviewed-on: https://chromium-review.googlesource.com/1191198 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Brian White <bcwhite@chromium.org> Cr-Commit-Position: refs/heads/master@{#595540} [modify] https://crrev.com/31e4dccfb1777b8a6c31255872682d10bc32492c/chromecast/browser/metrics/external_metrics.cc
,
Oct 1
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/961f444839ecdfa01ba0822e2cc9f4aecff8d2ed commit 961f444839ecdfa01ba0822e2cc9f4aecff8d2ed Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Mon Oct 01 22:15:17 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/prefs. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=pam@chromium.org Bug: 874080 Change-Id: I7ca5bf1e7d05dafa3ba1b2d96ff5d6af1278df17 Reviewed-on: https://chromium-review.googlesource.com/1191137 Reviewed-by: Robert Liao <robliao@chromium.org> Reviewed-by: Pam Greene (Please send IM for reviews) <pam@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#595574} [modify] https://crrev.com/961f444839ecdfa01ba0822e2cc9f4aecff8d2ed/chrome/browser/prefs/incognito_mode_prefs.cc
,
Oct 2
Issue 886668 has been merged into this issue.
,
Oct 2
,
Oct 2
,
Oct 2
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bfd5389ed3c23271a7e7ab94a5a77e4139326cb4 commit bfd5389ed3c23271a7e7ab94a5a77e4139326cb4 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Oct 02 15:53:46 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/apps/app_shim/app_shim_host_manager_mac.mm. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=thakis@chromium.org Bug: 874080 Change-Id: I449d164d700298ec166451458a5f9b135514156d Reviewed-on: https://chromium-review.googlesource.com/1190933 Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Trent Apted <tapted@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#595857} [modify] https://crrev.com/bfd5389ed3c23271a7e7ab94a5a77e4139326cb4/chrome/browser/apps/app_shim/app_shim_host_manager_mac.mm
,
Oct 3
,
Oct 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2b798e975c6cdb02dee93bdaf184276ad21d4be9 commit 2b798e975c6cdb02dee93bdaf184276ad21d4be9 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Oct 03 17:38:41 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/extensions/api/braille_display_private. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=aboxhall@chromium.org Bug: 874080 Change-Id: I3f749884b51d34136fff66d253ef71e2be34a335 Reviewed-on: https://chromium-review.googlesource.com/1191233 Reviewed-by: Alice Boxhall <aboxhall@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#596274} [modify] https://crrev.com/2b798e975c6cdb02dee93bdaf184276ad21d4be9/chrome/browser/extensions/api/braille_display_private/braille_controller_brlapi.cc
,
Oct 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0ba7f4d0d7324e5ad48f21e2da58217b758616f1 commit 0ba7f4d0d7324e5ad48f21e2da58217b758616f1 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Oct 09 20:52:04 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /components/storage_monitor. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation: MAY_BLOCK: The call might block (e.g. file I/O that might hit in memory cache). WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging server synchronously). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. Bug: 874080 Change-Id: I16428f52c0ee0037d6534aab2f683572687c9d7c Reviewed-on: https://chromium-review.googlesource.com/c/1191805 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#598074} [modify] https://crrev.com/0ba7f4d0d7324e5ad48f21e2da58217b758616f1/components/storage_monitor/image_capture_device.mm [modify] https://crrev.com/0ba7f4d0d7324e5ad48f21e2da58217b758616f1/components/storage_monitor/media_storage_util.cc [modify] https://crrev.com/0ba7f4d0d7324e5ad48f21e2da58217b758616f1/components/storage_monitor/mtab_watcher_linux.cc [modify] https://crrev.com/0ba7f4d0d7324e5ad48f21e2da58217b758616f1/components/storage_monitor/portable_device_watcher_win.cc [modify] https://crrev.com/0ba7f4d0d7324e5ad48f21e2da58217b758616f1/components/storage_monitor/storage_monitor_linux.cc [modify] https://crrev.com/0ba7f4d0d7324e5ad48f21e2da58217b758616f1/components/storage_monitor/storage_monitor_mac.mm
,
Oct 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1c4872a9ed1da5e3521375d05c9fddf186079fd1 commit 1c4872a9ed1da5e3521375d05c9fddf186079fd1 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Oct 09 21:58:01 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /extensions. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation: MAY_BLOCK: The call might block (e.g. file I/O that might hit in memory cache). WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging server synchronously). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=lazyboy@chromium.org Bug: 874080 Change-Id: I9fc177444966ae7b93e0a5cecc7e0ce3dd72a635 Reviewed-on: https://chromium-review.googlesource.com/c/1191197 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#598094} [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/content_hash_reader.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/content_verifier/content_hash.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/value_store/lazy_leveldb.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/value_store/legacy_value_store_factory.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/value_store/leveldb_scoped_database.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/value_store/leveldb_value_store.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/browser/zipfile_installer.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/common/file_util.cc [modify] https://crrev.com/1c4872a9ed1da5e3521375d05c9fddf186079fd1/extensions/common/manifest_handler.cc
,
Oct 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/15380ff4ce7c24db84b5d69b294da773429a76ca commit 15380ff4ce7c24db84b5d69b294da773429a76ca Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Oct 10 22:12:39 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /extensions/browser/api. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation: MAY_BLOCK: The call might block (e.g. file I/O that might hit in memory cache). WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging server synchronously). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tbarzic@chromium.org Bug: 874080 Change-Id: I453a66d52bc596d2594905e7bec58c6672ff4450 Reviewed-on: https://chromium-review.googlesource.com/c/1191791 Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#598536} [modify] https://crrev.com/15380ff4ce7c24db84b5d69b294da773429a76ca/extensions/browser/api/declarative_net_request/ruleset_matcher.cc [modify] https://crrev.com/15380ff4ce7c24db84b5d69b294da773429a76ca/extensions/browser/api/declarative_net_request/test_utils.cc [modify] https://crrev.com/15380ff4ce7c24db84b5d69b294da773429a76ca/extensions/browser/api/declarative_net_request/utils.cc [modify] https://crrev.com/15380ff4ce7c24db84b5d69b294da773429a76ca/extensions/browser/api/execute_code_function.cc
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/265ee88f7cf4a7ebba176038325fe356f153a972 commit 265ee88f7cf4a7ebba176038325fe356f153a972 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Oct 12 14:50:47 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks in /components/metrics. This CL uses ScopedBlockingCall to mark blocking calls in /components/metrics. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. Bug: 874080 Change-Id: Ifa1cba993d25114f81984771e50d4734ef66a954 Reviewed-on: https://chromium-review.googlesource.com/c/1191325 Reviewed-by: Alexei Svitkine <asvitkine@chromium.org> Commit-Queue: Alexei Svitkine <asvitkine@chromium.org> Cr-Commit-Position: refs/heads/master@{#599210} [modify] https://crrev.com/265ee88f7cf4a7ebba176038325fe356f153a972/base/metrics/persistent_memory_allocator.cc
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/493b6ac5dc96722f02d96ce86c201e1d273eb1a8 commit 493b6ac5dc96722f02d96ce86c201e1d273eb1a8 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Oct 12 19:00:41 2018 Remove unnecessary AssertBlockingAllowed() in /components/filename_generation. ScopedBlockingCall is now used to label blocking calls. There is no need to annotate calls to blocking //base APIs (base::File) since those are already annotated. Original CL intention was: This CL uses ScopedBlockingCall to mark blocking calls in /components/filename_generation. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. Bug: 874080 Change-Id: Iaa06bd88ea651b96f69b594158ee859124b890d8 Reviewed-on: https://chromium-review.googlesource.com/c/1191662 Reviewed-by: David Trainor <dtrainor@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#599313} [modify] https://crrev.com/493b6ac5dc96722f02d96ce86c201e1d273eb1a8/components/filename_generation/filename_generation.cc
,
Oct 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bfe8ae4ede445cf8b2e3a83e16c9229f317f3805 commit bfe8ae4ede445cf8b2e3a83e16c9229f317f3805 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Sat Oct 13 00:48:50 2018 Remove unnecessary AssertBlockingAllowed() in /chrome/browser/notifications/win/. ScopedBlockingCall is now used to label blocking calls. There is no need to annotate calls to blocking //base APIs (base::File) since those are already annotated. Original CL intention was: This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/notifications/win. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. Bug: 874080 Change-Id: I0b94734c783c893828eff7f60ac90c6152bcd1e1 Reviewed-on: https://chromium-review.googlesource.com/c/1191723 Reviewed-by: Xi Cheng <chengx@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#599449} [modify] https://crrev.com/bfe8ae4ede445cf8b2e3a83e16c9229f317f3805/chrome/browser/notifications/win/notification_image_retainer.cc
,
Oct 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b5110af2e9030044e3f2420b03ed04784c8df119 commit b5110af2e9030044e3f2420b03ed04784c8df119 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Tue Oct 16 13:12:28 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/ui/views/frame. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. Bug: 874080 Change-Id: I6664a62f27ae599144ffcac09f43aaf48e1948d3 Reviewed-on: https://chromium-review.googlesource.com/c/1194328 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Bret Sepulveda <bsep@chromium.org> Cr-Commit-Position: refs/heads/master@{#599960} [modify] https://crrev.com/b5110af2e9030044e3f2420b03ed04784c8df119/chrome/browser/ui/views/frame/browser_root_view.cc
,
Oct 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b77da511d53b598dd8988da83045f17833efac63 commit b77da511d53b598dd8988da83045f17833efac63 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Oct 17 15:05:43 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/extensions/api. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation: MAY_BLOCK: The call might block (e.g. file I/O that might hit in memory cache). WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging server synchronously). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=tbarzic@chromium.org Bug: 874080 Change-Id: I2d289daff2684837a6be032e5ca1e5acf37ad3cf Reviewed-on: https://chromium-review.googlesource.com/c/1194105 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#600392} [modify] https://crrev.com/b77da511d53b598dd8988da83045f17833efac63/chrome/browser/extensions/api/image_writer_private/image_writer_utility_client.cc [modify] https://crrev.com/b77da511d53b598dd8988da83045f17833efac63/chrome/browser/extensions/api/image_writer_private/image_writer_utility_client_browsertest.cc [modify] https://crrev.com/b77da511d53b598dd8988da83045f17833efac63/chrome/browser/extensions/api/image_writer_private/operation.cc [modify] https://crrev.com/b77da511d53b598dd8988da83045f17833efac63/chrome/browser/extensions/api/image_writer_private/removable_storage_provider_mac.cc [modify] https://crrev.com/b77da511d53b598dd8988da83045f17833efac63/chrome/browser/extensions/api/page_capture/page_capture_api.cc
,
Oct 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a77c4e0ebcf65032537f1fb21f2e7cad609ed97 commit 7a77c4e0ebcf65032537f1fb21f2e7cad609ed97 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Wed Oct 17 15:38:34 2018 [Task Scheduler]: Merge blocking and non-blocking pools. This CL creates a feature experiment that removes blocking worker pools from the task scheduler. Tasks with MayBlock trait are instead posted to the usual foreground/background pool, giving us better control over scheduling. Note: ScopedBlockingCall is used to add extra workers to the pool when a task is blocking. In this CL, we take advantage of this behavior to make sure enough workers are running on the CPU. Bug: 874080 Change-Id: I7889a941f82203388c259b0d96073eb5ddf3de69 Reviewed-on: https://chromium-review.googlesource.com/c/1249836 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: François Doray <fdoray@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Reviewed-by: Robert Kaplow (sloooow) <rkaplow@chromium.org> Cr-Commit-Position: refs/heads/master@{#600401} [modify] https://crrev.com/7a77c4e0ebcf65032537f1fb21f2e7cad609ed97/base/task/task_scheduler/task_scheduler_impl.cc [modify] https://crrev.com/7a77c4e0ebcf65032537f1fb21f2e7cad609ed97/base/task/task_scheduler/task_scheduler_impl.h [modify] https://crrev.com/7a77c4e0ebcf65032537f1fb21f2e7cad609ed97/base/task/task_scheduler/task_scheduler_impl_unittest.cc [modify] https://crrev.com/7a77c4e0ebcf65032537f1fb21f2e7cad609ed97/testing/variations/fieldtrial_testing_config.json
,
Oct 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a4195e59f50a96db73dae013a7b5ccf78711e60b commit a4195e59f50a96db73dae013a7b5ccf78711e60b Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Thu Oct 18 16:36:42 2018 [TaskScheduler]: Deprecate AssertBlockingAllowed. Usage of AssertBlockingAllowed outside of base:: is being replaced by ScopedBlockingCall. This CL puts AssertBlockingAllowed() into base::internal and adds AssertBlockingAllowedDeprecated for compatibility with current usage. This is a purely mechanical change with no side-effects. TBR=fdoray@chromium.org Bug: 874080 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I2b482a5ca217a563052dcae4afc45553626aa3d3 Reviewed-on: https://chromium-review.googlesource.com/c/1278540 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Reviewed-by: François Doray <fdoray@chromium.org> Cr-Commit-Position: refs/heads/master@{#600793} [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/android_webview/browser/aw_contents_io_thread_client.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/android_webview/browser/aw_variations_service_client.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/base/task/task_scheduler/task_tracker_unittest.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/base/threading/platform_thread_win.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/base/threading/scoped_blocking_call.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/base/threading/thread_restrictions.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/base/threading/thread_restrictions.h [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/base/threading/thread_restrictions_unittest.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/android/webapk/webapk_installer.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/app_controller_mac.mm [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/apps/platform_apps/api/music_manager_private/device_id_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/apps/platform_apps/api/music_manager_private/device_id_mac.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/apps/platform_apps/api/music_manager_private/device_id_win.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/chromeos/power/process_data_collector_unittest.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/extensions/external_pref_loader.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/extensions/external_registry_loader_win.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/extensions/unpacked_installer.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/extensions/webstore_installer.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/ui/app_list/search/search_result_ranker/app_search_result_ranker.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/browser/ui/webui/chromeos/login/l10n_util.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/chrome/chrome_cleaner/components/system_report_component.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/components/download/quarantine/test_support_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/components/download/quarantine/test_support_mac.mm [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/content/browser/tracing/tracing_controller_impl_data_endpoint.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/content/common/mac/font_loader.mm [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/ios/chrome/browser/sessions/session_service_ios.mm [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/media/audio/audio_debug_file_writer.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/media/capture/video/file_video_capture_device_factory.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/net/base/address_tracker_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/net/base/network_interfaces_getifaddrs.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/net/base/network_interfaces_win.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/net/dns/dns_config_service_win.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/printing/backend/cups_jobs.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/printing/printed_document.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/services/device/generic_sensor/linux/sensor_device_manager.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/services/device/generic_sensor/platform_sensor_reader_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/services/device/hid/hid_connection_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/services/device/hid/hid_service_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/services/device/hid/input_service_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/services/device/time_zone_monitor/time_zone_monitor_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/sql/database.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/sql/database.h [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/storage/browser/blob/blob_memory_controller.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/storage/browser/quota/quota_settings.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/third_party/leveldatabase/env_chromium.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/ui/base/win/shell.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/ui/events/devices/device_util_linux.cc [modify] https://crrev.com/a4195e59f50a96db73dae013a7b5ccf78711e60b/ui/ozone/platform/drm/host/drm_device_handle.cc
,
Oct 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/57a25b9fc1c704b0267f02f18d51680d57679152 commit 57a25b9fc1c704b0267f02f18d51680d57679152 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Oct 19 10:27:30 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /content/browser/tracing. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation: MAY_BLOCK: The call might block (e.g. file I/O that might hit in memory cache). WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging server synchronously). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. R=simonhatch@chromium.org Bug: 874080 Change-Id: I947898f0650e7a14a3133a4114c7fc30f326dedc Reviewed-on: https://chromium-review.googlesource.com/c/1191806 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: oysteine <oysteine@chromium.org> Cr-Commit-Position: refs/heads/master@{#601102} [modify] https://crrev.com/57a25b9fc1c704b0267f02f18d51680d57679152/content/browser/tracing/tracing_controller_impl_data_endpoint.cc
,
Oct 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f35cfff25c14541157baac2fe8014b3bf825e766 commit f35cfff25c14541157baac2fe8014b3bf825e766 Author: Christian Dullweber <dullweber@chromium.org> Date: Fri Oct 19 10:49:09 2018 Revert "[Task Scheduler]: Merge blocking and non-blocking pools." This reverts commit 7a77c4e0ebcf65032537f1fb21f2e7cad609ed97. Reason for revert: Findit identified that this introduced flakiness and it looks reasonable. Please take a look Original change's description: > [Task Scheduler]: Merge blocking and non-blocking pools. > > This CL creates a feature experiment that removes blocking worker pools > from the task scheduler. Tasks with MayBlock trait are instead posted to > the usual foreground/background pool, giving us better control over scheduling. > > Note: ScopedBlockingCall is used to add extra workers to the pool when a task is > blocking. In this CL, we take advantage of this behavior to make sure enough > workers are running on the CPU. > > Bug: 874080 > Change-Id: I7889a941f82203388c259b0d96073eb5ddf3de69 > Reviewed-on: https://chromium-review.googlesource.com/c/1249836 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: François Doray <fdoray@chromium.org> > Reviewed-by: Gabriel Charette <gab@chromium.org> > Reviewed-by: Robert Kaplow (sloooow) <rkaplow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#600401} TBR=gab@chromium.org,fdoray@chromium.org,rkaplow@chromium.org,etiennep@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 874080, 897014 Change-Id: I5d125aba916dfb0dfce791b4d0a5b1ca5e6035d9 Reviewed-on: https://chromium-review.googlesource.com/c/1290152 Reviewed-by: Christian Dullweber <dullweber@chromium.org> Commit-Queue: Christian Dullweber <dullweber@chromium.org> Cr-Commit-Position: refs/heads/master@{#601106} [modify] https://crrev.com/f35cfff25c14541157baac2fe8014b3bf825e766/base/task/task_scheduler/task_scheduler_impl.cc [modify] https://crrev.com/f35cfff25c14541157baac2fe8014b3bf825e766/base/task/task_scheduler/task_scheduler_impl.h [modify] https://crrev.com/f35cfff25c14541157baac2fe8014b3bf825e766/base/task/task_scheduler/task_scheduler_impl_unittest.cc [modify] https://crrev.com/f35cfff25c14541157baac2fe8014b3bf825e766/testing/variations/fieldtrial_testing_config.json
,
Oct 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a41391d4242b23b36f765d3b47607bb5ff0f8f59 commit a41391d4242b23b36f765d3b47607bb5ff0f8f59 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Oct 19 12:28:38 2018 Reland "[Task Scheduler]: Merge blocking and non-blocking pools." This is a reland of 7a77c4e0ebcf65032537f1fb21f2e7cad609ed97 Death test should run in single thread. Adding testing::GTEST_FLAG(death_test_style) = "threadsafe"; before EXPECT_DCHECK_DEATH() to fix flakiness. Original change's description: > [Task Scheduler]: Merge blocking and non-blocking pools. > > This CL creates a feature experiment that removes blocking worker pools > from the task scheduler. Tasks with MayBlock trait are instead posted to > the usual foreground/background pool, giving us better control over scheduling. > > Note: ScopedBlockingCall is used to add extra workers to the pool when a task is > blocking. In this CL, we take advantage of this behavior to make sure enough > workers are running on the CPU. > > Bug: 874080 > Change-Id: I7889a941f82203388c259b0d96073eb5ddf3de69 > Reviewed-on: https://chromium-review.googlesource.com/c/1249836 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: François Doray <fdoray@chromium.org> > Reviewed-by: Gabriel Charette <gab@chromium.org> > Reviewed-by: Robert Kaplow (sloooow) <rkaplow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#600401} TBR=rkaplow@chromium.org Bug: 874080 Change-Id: I54665c798d332eead0f81da0f15c93368ec883a8 Reviewed-on: https://chromium-review.googlesource.com/c/1290911 Commit-Queue: François Doray <fdoray@chromium.org> Reviewed-by: François Doray <fdoray@chromium.org> Cr-Commit-Position: refs/heads/master@{#601122} [modify] https://crrev.com/a41391d4242b23b36f765d3b47607bb5ff0f8f59/base/task/task_scheduler/task_scheduler_impl.cc [modify] https://crrev.com/a41391d4242b23b36f765d3b47607bb5ff0f8f59/base/task/task_scheduler/task_scheduler_impl.h [modify] https://crrev.com/a41391d4242b23b36f765d3b47607bb5ff0f8f59/base/task/task_scheduler/task_scheduler_impl_unittest.cc [modify] https://crrev.com/a41391d4242b23b36f765d3b47607bb5ff0f8f59/testing/variations/fieldtrial_testing_config.json
,
Oct 23
Starting to get results from experiments [1], it looks promising. The experiment significantly reduces TaskScheduler.HeartbeatLatencyMicroseconds.*, by as much as -70% for most percentiles, which is surprising. Heartbeat metrics don't seem to be affected, with the exception of a 5% regression on Event.Latency.ScrollUpdate.Touch.TimeToScrollUpdateSwapBegin4 for some percentiles. Will wait for a bit more data to see if this is really an issue. [1]: https://uma.googleplex.com/p/chrome/variations/?sid=5e122914fc0760e8b792efc0a746cd98
,
Oct 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a1e81dfd31f18630113632a543b42b542ef3f4ef commit a1e81dfd31f18630113632a543b42b542ef3f4ef Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Wed Oct 24 15:26:38 2018 [TaskScheduler]: Use ScopedBlockingCall to mark blocking tasks. This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/apps/platform_apps/. This CL was created by replacing calls to AssertBlockingAllowed() with instantiations of ScopedBlockingCall(MAY_BLOCK). I kindly ask the reviewer to make sure of the following: - ScopedBlockingCall is instantiated in a scope with minimal CPU usage. If this is not the case, ScopedBlockingCall should be instantiated closer to the blocking call. See scoped_blocking_call.h for more info. Please let me know when/where the blocking call happens if this needs to be changed. - Parameter |blocking_type| matches expectation: MAY_BLOCK: The call might block (e.g. file I/O that might hit in memory cache). WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging server synchronously). See BlockingType for more info. While I assumed MAY_BLOCK by default, that might not be the best fit if we know that this callsite is guaranteed to block. - The ScopedBlockingCall's scope covers the entirety of the blocking operation previously asserted against by the AssertBlockingAllowed(). This CL was uploaded by git cl split. TBR=dominickn@chromium.org Bug: 874080 Change-Id: Iceac744a259b8feaba56efc153c0eaed7392cf90 Reviewed-on: https://chromium-review.googlesource.com/c/1255601 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#602344} [modify] https://crrev.com/a1e81dfd31f18630113632a543b42b542ef3f4ef/chrome/browser/apps/platform_apps/api/music_manager_private/device_id_linux.cc [modify] https://crrev.com/a1e81dfd31f18630113632a543b42b542ef3f4ef/chrome/browser/apps/platform_apps/api/music_manager_private/device_id_mac.cc [modify] https://crrev.com/a1e81dfd31f18630113632a543b42b542ef3f4ef/chrome/browser/apps/platform_apps/api/music_manager_private/device_id_win.cc
,
Nov 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2987cc81690c23bda627edce0195af69e4a6b1b5 commit 2987cc81690c23bda627edce0195af69e4a6b1b5 Author: Leszek Swirski <leszeks@chromium.org> Date: Mon Nov 05 15:19:28 2018 [blink] Disable streaming task reposting for merged pools Disable the script streaming task repost when the blocking and non-blocking pools merge flag is enabled. Eventually, we can hopefully remove this hack entirely. Bug: 874080 Change-Id: Ifcf82a4ef95d27cf99d4cbb106f8bed9bb6d7f21 Reviewed-on: https://chromium-review.googlesource.com/c/1293915 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#605334} [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/base/BUILD.gn [add] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/base/task/task_features.cc [add] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/base/task/task_features.h [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/base/task/task_scheduler/task_scheduler_impl.cc [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/base/task/task_scheduler/task_scheduler_impl.h [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/base/task/task_scheduler/task_scheduler_impl_unittest.cc [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/content/child/runtime_features.cc [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/third_party/blink/public/platform/web_runtime_features.h [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/third_party/blink/renderer/bindings/core/v8/script_streamer.cc [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/third_party/blink/renderer/bindings/core/v8/script_streamer.h [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/third_party/blink/renderer/platform/exported/web_runtime_features.cc [modify] https://crrev.com/2987cc81690c23bda627edce0195af69e4a6b1b5/third_party/blink/renderer/platform/runtime_enabled_features.json5
,
Nov 21
What is the current status of this work?
,
Nov 21
We're seeing regression of 3.5% on NewTabPage.LoadTime at 99%ile for this experiment, so I'm doing more investigation. Since merging pool relies on ScopeBlockingCall to replace blocked threads, I'm experimenting on adjusting timings of ScopeBlockingCall(MAY_BLOCK): https://chromium-review.googlesource.com/c/chromium/src/+/1337276 Current behavior is ~50ms delay before a blocked thread can be replaced, which is probably way too long.
,
Nov 21
Ok, great, thanks. FYI I'm relanding the field trial for scheduled script streaming (which I forgot to reland, oops), so you may see the effects of that soon. Any improvements, or just that regression?
,
Nov 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d6b575b24da702a15692b65b3291708c383e8a6c commit d6b575b24da702a15692b65b3291708c383e8a6c Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Wed Nov 21 19:32:29 2018 [TaskScheduler]: Create may block delay experiment. Turn may_block_threshold and blocked_workers_poll_period into finch parameters under the experiment kMayBlockAdjustTasksTiming. Bug: 874080 Change-Id: I0104b68a96b08e9bf318258e75869555ab39e54b Reviewed-on: https://chromium-review.googlesource.com/c/1337276 Reviewed-by: Gabriel Charette <gab@chromium.org> Reviewed-by: François Doray <fdoray@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#610159} [modify] https://crrev.com/d6b575b24da702a15692b65b3291708c383e8a6c/base/task/task_features.cc [modify] https://crrev.com/d6b575b24da702a15692b65b3291708c383e8a6c/base/task/task_features.h [modify] https://crrev.com/d6b575b24da702a15692b65b3291708c383e8a6c/base/task/task_scheduler/scheduler_worker_pool_impl.cc [modify] https://crrev.com/d6b575b24da702a15692b65b3291708c383e8a6c/base/task/task_scheduler/scheduler_worker_pool_impl.h [modify] https://crrev.com/d6b575b24da702a15692b65b3291708c383e8a6c/base/task/task_scheduler/scheduler_worker_pool_impl_unittest.cc
,
Nov 22
We're seeing huge improvement on TaskScheduler.HeartbeatLatencyMicroseconds for non-blocking tasks (as much as 60%) at all %ile. This is due to reusing threads from blocking tasks; it's mostly a "re-prioritization" of tasks though, and blocking tasks sometimes have higher latency as a result. No top-level heartbeat metric was improved :(
,
Dec 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eba21493c680572aa8f4ebcb22aeed160847e17a commit eba21493c680572aa8f4ebcb22aeed160847e17a Author: Wez <wez@chromium.org> Date: Wed Dec 05 18:24:17 2018 Replace useless logging of |errno| with PLOG variants. In https://chromium-review.googlesource.com/c/chromium/src/+/1220172/ base::LogMessage was modified to save & restore errno, to avoid the logging implementation trampling over the value. Remove a load of now-redundant attempts to explicitly log errno, in most cases replacing them with PLOG & variants. Bug: 874080 Change-Id: Ic641a16b1069907a341ea56e5a9e5e6d0aeaacdc Reviewed-on: https://chromium-review.googlesource.com/c/1361799 Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Will Harris <wfh@chromium.org> Commit-Queue: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#614031} [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/base/files/dir_reader_linux.h [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/base/memory/shared_memory_helper.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/base/message_loop/message_pump_libevent.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/base/process/internal_aix.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/base/rand_util_posix.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/chrome/browser/chromeos/app_mode/app_session.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/components/crash/content/browser/crash_handler_host_linux.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/components/offline_pages/core/offline_page_archiver.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/components/quirks/quirks_client.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/net/dns/host_resolver_impl.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/net/socket/socket_posix.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/net/socket/udp_socket_posix.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/net/ssl/openssl_ssl_util.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/remoting/host/posix/signal_handler.cc [modify] https://crrev.com/eba21493c680572aa8f4ebcb22aeed160847e17a/services/service_manager/zygote/host/zygote_communication_linux.cc
Showing comments 34 - 133
of 133
Older ›
|
|||||
►
Sign in to add a comment |
|||||
