Annotate blocking calls with base ScopeBlockingCall |
|
Issue descriptionCalls that block off-cpu should be annotated. The annotation serves the scheduler, and as documentation. Trace events are associated with this annotation, which makes it easy to identify undocumented blocking behaviors from traces. For wait on synchronous file or I/O operations, ScopedBlockingCall should be used. For sync primitives in base, ScopedBlockingCallWithBaseSyncPrimitives should be used.
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2f97450641fdc43f7ac6555fad0d47c83f540646 commit 2f97450641fdc43f7ac6555fad0d47c83f540646 Author: Etienne Pierre-doray <etiennep@chromium.org> Date: Fri Nov 16 14:32:49 2018 [TaskScheduler]: Document Process::WaitForExitWithTimeout as not considered blocking. Original CL intention was: Use ScopedBlockingCallWithBaseSyncPrimitives to annotate sync primitives. Migrate AssertBaseSyncPrimitivesAllowed() to ScopedBlockingCallWithBaseSyncPrimitives in base::Process. Bug: 903957, 905788 Change-Id: Ief5072d7e9b9feaf1ee7b817add26545bf80b78a Reviewed-on: https://chromium-review.googlesource.com/c/1324418 Reviewed-by: François Doray <fdoray@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: François Doray <fdoray@chromium.org> Cr-Commit-Position: refs/heads/master@{#608768} [modify] https://crrev.com/2f97450641fdc43f7ac6555fad0d47c83f540646/base/process/process_posix.cc [modify] https://crrev.com/2f97450641fdc43f7ac6555fad0d47c83f540646/base/process/process_win.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8784b7c744fa48a5835a3f2534cf5ab17ac23977 commit 8784b7c744fa48a5835a3f2534cf5ab17ac23977 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 15:00:53 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /components/download/quarantine base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=asanka@chromium.org Bug: 903957 Change-Id: I7ae73e710d70fb3872942b50b7c26285cad73571 Reviewed-on: https://chromium-review.googlesource.com/c/1338124 Reviewed-by: Asanka Herath <asanka@chromium.org> Commit-Queue: Asanka Herath <asanka@chromium.org> Cr-Commit-Position: refs/heads/master@{#608779} [modify] https://crrev.com/8784b7c744fa48a5835a3f2534cf5ab17ac23977/components/download/quarantine/test_support_linux.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0eed991aefb9dab90ac66f96d953323f0149962b commit 0eed991aefb9dab90ac66f96d953323f0149962b Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 16:57:50 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /third_party/leveldatabase base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=pwnall@chromium.org Bug: 903957 Change-Id: I81021e9c637e588b0cdcc464218df1770cedc635 Reviewed-on: https://chromium-review.googlesource.com/c/1338128 Reviewed-by: Victor Costan <pwnall@chromium.org> Commit-Queue: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#608812} [modify] https://crrev.com/0eed991aefb9dab90ac66f96d953323f0149962b/third_party/leveldatabase/env_chromium.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/57cf470cf610f98aaa5c9cf86dc929d1cce57cb9 commit 57cf470cf610f98aaa5c9cf86dc929d1cce57cb9 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 17:04:14 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /storage/browser/quota base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=kinuko@chromium.org Bug: 903957 Change-Id: I55e70c8b849dd626cc9f51d03d4e2fd15d7d2e8c Reviewed-on: https://chromium-review.googlesource.com/c/1338123 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#608814} [modify] https://crrev.com/57cf470cf610f98aaa5c9cf86dc929d1cce57cb9/storage/browser/quota/quota_settings.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b63ceeb6525cc827e682af08d447284215f8e19f commit b63ceeb6525cc827e682af08d447284215f8e19f Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 17:17:59 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /ui/events base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=sadrul@chromium.org Bug: 903957 Change-Id: I350657e7c0760b9ce1e4ff33a74a0e8e007d5e21 Reviewed-on: https://chromium-review.googlesource.com/c/1338409 Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#608823} [modify] https://crrev.com/b63ceeb6525cc827e682af08d447284215f8e19f/ui/events/devices/device_util_linux.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/48b9cf1a60a430eb6e3a7e6af2049b933367d99d commit 48b9cf1a60a430eb6e3a7e6af2049b933367d99d Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 17:19:23 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /ui base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=avi@chromium.org Bug: 903957 Change-Id: I86f204337a4137c79f85eb73e5601b9a02fe578a Reviewed-on: https://chromium-review.googlesource.com/c/1338489 Reviewed-by: Avi Drissman <avi@chromium.org> Commit-Queue: Avi Drissman <avi@chromium.org> Cr-Commit-Position: refs/heads/master@{#608824} [modify] https://crrev.com/48b9cf1a60a430eb6e3a7e6af2049b933367d99d/ui/base/win/shell.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/58ed9bb8fc6e37e61ae7a0a376d560fb89c85415 commit 58ed9bb8fc6e37e61ae7a0a376d560fb89c85415 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 17:42:34 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /media/capture/video base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=emircan@chromium.org Bug: 903957 Change-Id: Icb47a6a89a0c8e3c1a2871064dbb5b105db0ba2f Reviewed-on: https://chromium-review.googlesource.com/c/1338412 Reviewed-by: Emircan Uysaler <emircan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#608842} [modify] https://crrev.com/58ed9bb8fc6e37e61ae7a0a376d560fb89c85415/media/capture/video/file_video_capture_device_factory.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/faf733701ae572be3fa178d87071ab5e29acaf8f commit faf733701ae572be3fa178d87071ab5e29acaf8f Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 18:42:52 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /media/audio base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=henrika@chromium.org Bug: 903957 Change-Id: Id9a9bb29d5d9beb2f680472602badc3a1ac1f6e3 Reviewed-on: https://chromium-review.googlesource.com/c/1338126 Reviewed-by: Max Morin <maxmorin@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#608866} [modify] https://crrev.com/faf733701ae572be3fa178d87071ab5e29acaf8f/media/audio/audio_debug_file_writer.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bb837b9015da4fca74af273516bd096b3e07fb0a commit bb837b9015da4fca74af273516bd096b3e07fb0a Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 18:48:06 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /android_webview base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=torne@chromium.org Bug: 903957 Change-Id: Iaf80012bf6f5c5f7852031c21f68c75e11957ca1 Reviewed-on: https://chromium-review.googlesource.com/c/1338481 Reviewed-by: Richard Coles <torne@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#608869} [modify] https://crrev.com/bb837b9015da4fca74af273516bd096b3e07fb0a/android_webview/browser/aw_contents_io_thread_client.cc [modify] https://crrev.com/bb837b9015da4fca74af273516bd096b3e07fb0a/android_webview/browser/aw_variations_service_client.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/378cfabb35909356f48a1adf0c8e9d2690f869cc commit 378cfabb35909356f48a1adf0c8e9d2690f869cc Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 19:01:05 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /chrome/browser/ui/webui/chromeos/login base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=jdufault@chromium.org Bug: 903957 Change-Id: I884ec06bef124aef5b587bff4027e9014962c163 Reviewed-on: https://chromium-review.googlesource.com/c/1338487 Reviewed-by: Jacob Dufault <jdufault@chromium.org> Commit-Queue: Jacob Dufault <jdufault@chromium.org> Cr-Commit-Position: refs/heads/master@{#608876} [modify] https://crrev.com/378cfabb35909356f48a1adf0c8e9d2690f869cc/chrome/browser/ui/webui/chromeos/login/l10n_util.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a7eb1ec3c10905b07fb901f9aa75f5109ab2858 commit 7a7eb1ec3c10905b07fb901f9aa75f5109ab2858 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 19:36:09 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /services/device/generic_sensor base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=timvolodine@chromium.org Bug: 903957 Change-Id: Icaf8fe70611a4e937b69bca1c2a670a9a45ae5ac Reviewed-on: https://chromium-review.googlesource.com/c/1338129 Reviewed-by: Tim Volodine <timvolodine@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#608892} [modify] https://crrev.com/7a7eb1ec3c10905b07fb901f9aa75f5109ab2858/services/device/generic_sensor/linux/sensor_device_manager.cc
,
Nov 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8a342c22bee9953ddf985e51617f1dcb8e97b91b commit 8a342c22bee9953ddf985e51617f1dcb8e97b91b Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 16 20:10:45 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /chrome/browser/ui/app_list base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=jennyz@chromium.org Bug: 903957 Change-Id: Idc81701192f6879ee7e11e2f15e89292d9406f9e Reviewed-on: https://chromium-review.googlesource.com/c/1338414 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Jenny Zhang <jennyz@chromium.org> Cr-Commit-Position: refs/heads/master@{#608915} [modify] https://crrev.com/8a342c22bee9953ddf985e51617f1dcb8e97b91b/chrome/browser/ui/app_list/search/search_result_ranker/app_search_result_ranker.cc
,
Nov 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/758caee2ddcefd165feec87cd942f69358a34184 commit 758caee2ddcefd165feec87cd942f69358a34184 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Nov 19 15:58:02 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /printing base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=rbpotter@chromium.org Bug: 903957 Change-Id: Ia22660cd032410f40dba9f9f98ccff46d6eaaaf6 Reviewed-on: https://chromium-review.googlesource.com/c/1338488 Reviewed-by: Rebekah Potter <rbpotter@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#609313} [modify] https://crrev.com/758caee2ddcefd165feec87cd942f69358a34184/printing/printed_document.cc
,
Nov 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/563d6a0082ac1bc85fb42a69df97394e413f3d24 commit 563d6a0082ac1bc85fb42a69df97394e413f3d24 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Nov 19 18:36:28 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /services/device/time_zone_monitor base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=mark@chromium.org Bug: 903957 Change-Id: I2be2db1919ad6f58b47a8e66e47fa7a138684d87 Reviewed-on: https://chromium-review.googlesource.com/c/1338490 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Cr-Commit-Position: refs/heads/master@{#609362} [modify] https://crrev.com/563d6a0082ac1bc85fb42a69df97394e413f3d24/services/device/time_zone_monitor/time_zone_monitor_linux.cc
,
Nov 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6013fa2ba318ed1c074ed817daa1478446b58b64 commit 6013fa2ba318ed1c074ed817daa1478446b58b64 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Tue Nov 20 15:10:31 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /chrome/chrome_cleaner base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=csharp@chromium.org Bug: 903957 Change-Id: I5ff84cb3c4169e19e04d59e682916eb6632a848a Reviewed-on: https://chromium-review.googlesource.com/c/1338127 Reviewed-by: proberge <proberge@chromium.org> Commit-Queue: proberge <proberge@chromium.org> Cr-Commit-Position: refs/heads/master@{#609706} [modify] https://crrev.com/6013fa2ba318ed1c074ed817daa1478446b58b64/chrome/chrome_cleaner/components/system_report_component.cc
,
Nov 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2b2013209fcb143639a98461b5ea72c0d4d9b7a6 commit 2b2013209fcb143639a98461b5ea72c0d4d9b7a6 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Wed Nov 21 15:27:18 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /printing/backend/cups_jobs.cc base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=skau@chromium.org Bug: 903957 Change-Id: Icd6f4bf53daa45bf540611ededc97b941f09da88 Reviewed-on: https://chromium-review.googlesource.com/c/1338407 Reviewed-by: Sean Kau <skau@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#610064} [modify] https://crrev.com/2b2013209fcb143639a98461b5ea72c0d4d9b7a6/printing/backend/cups_jobs.cc
,
Nov 26
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141 commit 5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Nov 26 17:53:03 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /services/device base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=reillyg@chromium.org Bug: 903957 Change-Id: I232ee84dfca8770994440c95abf2eb17f0780e83 Reviewed-on: https://chromium-review.googlesource.com/c/1338485 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Reilly Grant <reillyg@chromium.org> Cr-Commit-Position: refs/heads/master@{#610879} [modify] https://crrev.com/5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141/device/base/device_monitor_linux.cc [modify] https://crrev.com/5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141/device/udev_linux/udev_watcher.cc [modify] https://crrev.com/5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141/services/device/hid/hid_connection_linux.cc [modify] https://crrev.com/5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141/services/device/hid/hid_service_linux.cc [modify] https://crrev.com/5ccb18ee6bcbe5d7f8b87478f80ff9ffcac90141/services/device/hid/input_service_linux.cc
,
Nov 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5e5c6c41ddeb02cd5fa1076ce928e827c46052db commit 5e5c6c41ddeb02cd5fa1076ce928e827c46052db Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Tue Nov 27 20:11:09 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /chrome/browser/extensions base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=finnur@chromium.org Bug: 903957 Change-Id: I461f534870c60e1fc6b9c1c441d388cc99646c10 Reviewed-on: https://chromium-review.googlesource.com/c/1338483 Reviewed-by: Finnur Thorarinsson <finnur@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#611279} [modify] https://crrev.com/5e5c6c41ddeb02cd5fa1076ce928e827c46052db/chrome/browser/extensions/external_pref_loader.cc [modify] https://crrev.com/5e5c6c41ddeb02cd5fa1076ce928e827c46052db/chrome/browser/extensions/external_registry_loader_win.cc [modify] https://crrev.com/5e5c6c41ddeb02cd5fa1076ce928e827c46052db/chrome/browser/extensions/unpacked_installer.cc [modify] https://crrev.com/5e5c6c41ddeb02cd5fa1076ce928e827c46052db/chrome/browser/extensions/webstore_installer.cc
,
Nov 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/260c537ad35d29d52a482255969dda9162892adc commit 260c537ad35d29d52a482255969dda9162892adc Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Wed Nov 28 15:09:52 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /net base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=davidben@chromium.org Bug: 903957 Change-Id: I7264546a54917ab0f7be6931219aad84091582aa Reviewed-on: https://chromium-review.googlesource.com/c/1338486 Reviewed-by: David Benjamin <davidben@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#611695} [modify] https://crrev.com/260c537ad35d29d52a482255969dda9162892adc/net/base/address_tracker_linux.cc [modify] https://crrev.com/260c537ad35d29d52a482255969dda9162892adc/net/base/network_interfaces_getifaddrs.cc [modify] https://crrev.com/260c537ad35d29d52a482255969dda9162892adc/net/base/network_interfaces_win.cc [modify] https://crrev.com/260c537ad35d29d52a482255969dda9162892adc/net/dns/dns_config_service_win.cc
,
Nov 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1e53af3ded28e1916daab2652e42f9926f21fad1 commit 1e53af3ded28e1916daab2652e42f9926f21fad1 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Nov 30 23:37:47 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /storage/browser/blob base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=jianli@chromium.org Bug: 903957 Change-Id: I05eabae1bc94d675e26a59ba61d862d536a8513d Reviewed-on: https://chromium-review.googlesource.com/c/1338394 Reviewed-by: Jian Li <jianli@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#612845} [modify] https://crrev.com/1e53af3ded28e1916daab2652e42f9926f21fad1/storage/browser/blob/blob_memory_controller.cc
,
Dec 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b4dd201fc92802170fa12b5311a21d35ea67207 commit 1b4dd201fc92802170fa12b5311a21d35ea67207 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Dec 03 17:36:02 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /ui/ozone/platform/drm base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=dnicoara@chromium.org Bug: 903957 Change-Id: Ie052b76a8c8c4083857f9deb5d46eb03e1cb15e6 Reviewed-on: https://chromium-review.googlesource.com/c/1338482 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Daniel Nicoara <dnicoara@chromium.org> Cr-Commit-Position: refs/heads/master@{#613139} [modify] https://crrev.com/1b4dd201fc92802170fa12b5311a21d35ea67207/ui/ozone/platform/drm/host/drm_device_handle.cc
,
Dec 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0400dfb6904e0733ffe4cab0c7719b79c810cf1f commit 0400dfb6904e0733ffe4cab0c7719b79c810cf1f Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Dec 03 19:12:25 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /sql base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=cmumford@chromium.org Bug: 903957 Change-Id: I0e677a2f89f333b999d71fa83f15646a97c53fb6 Reviewed-on: https://chromium-review.googlesource.com/c/1338415 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Chris Mumford <cmumford@chromium.org> Cr-Commit-Position: refs/heads/master@{#613183} [modify] https://crrev.com/0400dfb6904e0733ffe4cab0c7719b79c810cf1f/sql/database.cc [modify] https://crrev.com/0400dfb6904e0733ffe4cab0c7719b79c810cf1f/sql/database.h
,
Dec 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a620e5ec9ccbf30be37fd4004d95ed3c2032334d commit a620e5ec9ccbf30be37fd4004d95ed3c2032334d Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Thu Dec 06 19:02:10 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /chrome/browser/app_controller_mac.mm base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=mark@chromium.org Bug: 903957 Change-Id: I6b8a4fa67bfabb263bf80d78fb3ca8a295b3fcab Reviewed-on: https://chromium-review.googlesource.com/c/1366075 Reviewed-by: Mark Mentovai <mark@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#614433} [modify] https://crrev.com/a620e5ec9ccbf30be37fd4004d95ed3c2032334d/chrome/browser/app_controller_mac.mm
,
Dec 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e1b45c53c70e012f9e35d7588e7b0661d6ea1ca2 commit e1b45c53c70e012f9e35d7588e7b0661d6ea1ca2 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Fri Dec 07 16:20:47 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /components/download/quarantine base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=wfh@chromium.org Bug: 903957 Change-Id: I05f97174944bdfa66f032067fd90ac37a7523eaf Reviewed-on: https://chromium-review.googlesource.com/c/1366018 Reviewed-by: Will Harris <wfh@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#614716} [modify] https://crrev.com/e1b45c53c70e012f9e35d7588e7b0661d6ea1ca2/components/download/quarantine/test_support_mac.mm
,
Dec 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a22f10309f888b61e2e6b8398e2d90f133159c55 commit a22f10309f888b61e2e6b8398e2d90f133159c55 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Mon Dec 10 23:07:33 2018 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /ios/chrome/browser/sessions base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=rohitrao@chromium.org Bug: 903957 Change-Id: Ia75e29de3e32ef186bfdaac36c8644c4c125e5f4 Reviewed-on: https://chromium-review.googlesource.com/c/1366016 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Rohit Rao <rohitrao@chromium.org> Cr-Commit-Position: refs/heads/master@{#615303} [modify] https://crrev.com/a22f10309f888b61e2e6b8398e2d90f133159c55/ios/chrome/browser/sessions/session_service_ios.mm
,
Jan 16
(6 days ago)
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ffd976908696323692e2f34cefef9efc4f12d313 commit ffd976908696323692e2f34cefef9efc4f12d313 Author: Etienne Pierre-Doray <etiennep@chromium.org> Date: Wed Jan 16 15:48:23 2019 [TaskScheduler]: Migrate off of AssertBlockingAllowedDeprecated in /content/common/mac/font_loader.mm base::AssertBlockingAllowedDeprecated is deprecated in favor of ScopedBlockingCall, which serves as a precise annotation of the scope that may/will block. Please 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(). - Calls to blocking //base APIs don't need to be annotated with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read, base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their own internal annotations. Refer to the top-level CL if necessary : https://chromium-review.googlesource.com/c/chromium/src/+/1338391 Please CQ if LGTY! This CL was uploaded by git cl split. R=tapted@chromium.org Bug: 903957 Change-Id: Iac85ee6160e26265c7c41aace19f23fa9553ff46 Reviewed-on: https://chromium-review.googlesource.com/c/1365880 Reviewed-by: Trent Apted <tapted@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#623250} [modify] https://crrev.com/ffd976908696323692e2f34cefef9efc4f12d313/content/common/mac/font_loader.mm |
|
►
Sign in to add a comment |
|
Comment 1 by bugdroid1@chromium.org
, Nov 16