New issue
Advanced search Search tips

Issue 650723 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 825327
issue 653916



Sign in to add a comment

Remove calls to MessageLoop::current()

Project Member Reported by fdoray@chromium.org, Sep 27 2016

Issue description

MessageLoop::current() returns nullptr in TaskScheduler.

ThreadTaskRunnerHandle and ThreadChecker should be used when possible instead of MessageLoop::current().

E.g.

MessageLoop::current()->task_runner()
should be
ThreadTaskRunnerHandle::Get()

class MyClass {
  MyClass() {
    message_loop_ = MessageLoop::current();
  }

  void MyMethod() {
    DCHECK_EQ(message_loop_, MessageLoop::current());
  }

  MessageLoop* message_loop_;
};
should be
class MyClass {
  MyClass() = default;

  void MyMethod() {
    DCHECK(thread_checker_.CalledOnValidThread());
  }

  ThreadChecker thread_checker_;
};
 

Comment 1 by gab@chromium.org, Sep 27 2016

These replacements sound great to me :-)
Project Member

Comment 2 by bugdroid1@chromium.org, Sep 30 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/19e49e924e88e50546ec1a81dbc7b43ea4b172ef

commit 19e49e924e88e50546ec1a81dbc7b43ea4b172ef
Author: fdoray <fdoray@chromium.org>
Date: Fri Sep 30 20:42:16 2016

Replace MessageLoop::current()->task_runner() with ThreadTaskRunnerHandle::Get().

This CL makes the following replacements:

MessageLoop::current()->task_runner()
becomes
ThreadTaskRunnerHandle::Get()

MessageLoopForUIorIO::current()->task_runner()
becomes
DCHECK(MessageLoopForUIorIO::IsCurrent()); (or ASSERT_TRUE)
ThreadTaskRunnerHandle::Get()

TBR=gavinp@chromium.org
BUG= 650723 

Review-Url: https://codereview.chromium.org/2375663002
Cr-Commit-Position: refs/heads/master@{#422211}

[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ash/shelf/shelf_view_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/base/memory/ref_counted_delete_on_message_loop.h
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/base/message_loop/message_loop_test.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/base/message_loop/message_loop_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/base/message_loop/message_pump_libevent_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/chrome/browser/chromeos/login/easy_unlock/easy_unlock_reauth.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/chrome/browser/chromeos/login/login_ui_keyboard_browsertest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/chrome/browser/ui/ash/media_delegate_chromeos.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/chrome/browser/ui/views/chrome_views_delegate.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/chrome/browser/ui/views/menu_model_adapter_test.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/arc/arc_bridge_service_impl.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/browser_watcher/window_hang_monitor_win.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/browsing_data/content/conditional_cache_deletion_helper.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/favicon/core/large_icon_service_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/leveldb/leveldb_app.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/previews/core/previews_black_list_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/safe_browsing_db/v4_database.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/test_runner/mock_screen_orientation_client.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/components/update_client/component_patcher_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/content/browser/renderer_host/render_widget_host_view_mac_editcommand_helper_unittest.mm
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/content/browser/service_worker/service_worker_url_request_job_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/content/browser/webui/url_data_manager_backend.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/content/common/child_process_host_impl.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/content/public/test/test_renderer_host.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/device/generic_sensor/platform_sensor_android.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ipc/ipc_channel_reader.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ipc/ipc_channel_win.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/services/shell/standalone/context.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/services/shell/standalone/tracer.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/services/tracing/public/cpp/provider.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager_perftest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/third_party/libaddressinput/chromium/chrome_address_validator.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/third_party/zlib/google/zip_reader.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ui/aura/test/ui_controls_factory_aurawin.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ui/ozone/platform/wayland/wayland_connection.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ui/shell_dialogs/select_file_dialog_win.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ui/views/controls/menu/menu_controller_unittest.cc
[modify] https://crrev.com/19e49e924e88e50546ec1a81dbc7b43ea4b172ef/ui/views/widget/desktop_aura/x11_whole_screen_move_loop.cc

Project Member

Comment 3 by bugdroid1@chromium.org, Oct 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d97226d3b06bd96e376f6ab6975089a4744b7a7

commit 9d97226d3b06bd96e376f6ab6975089a4744b7a7
Author: fdoray <fdoray@chromium.org>
Date: Tue Oct 11 18:48:47 2016

Remove MessageLoop::current() from rendering_helper.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2407333002
Cr-Commit-Position: refs/heads/master@{#424497}

[modify] https://crrev.com/9d97226d3b06bd96e376f6ab6975089a4744b7a7/media/gpu/rendering_helper.cc
[modify] https://crrev.com/9d97226d3b06bd96e376f6ab6975089a4744b7a7/media/gpu/rendering_helper.h

Project Member

Comment 4 by bugdroid1@chromium.org, Oct 12 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee1e0f0692c8407eb77db45a19633d566821cf25

commit ee1e0f0692c8407eb77db45a19633d566821cf25
Author: fdoray <fdoray@chromium.org>
Date: Wed Oct 12 11:27:01 2016

Remove static_cast<base::MessageLoopForUI*> from aw_contents_client_bridge.cc.

In preparation for the migration of BrowserThreads to TaskScheduler,
we want to remove calls to MessageLoop::current().
MessageLoopForUI::current() is still supported.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2411823002
Cr-Commit-Position: refs/heads/master@{#424713}

[modify] https://crrev.com/ee1e0f0692c8407eb77db45a19633d566821cf25/android_webview/native/aw_contents_client_bridge.cc

Project Member

Comment 5 by bugdroid1@chromium.org, Oct 12 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f155f05fffa8d3a7dc3cba15579415800d5668c

commit 4f155f05fffa8d3a7dc3cba15579415800d5668c
Author: fdoray <fdoray@chromium.org>
Date: Wed Oct 12 11:28:50 2016

Remove MessageLoop::current() from browser_context.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2407353002
Cr-Commit-Position: refs/heads/master@{#424715}

[modify] https://crrev.com/4f155f05fffa8d3a7dc3cba15579415800d5668c/content/browser/browser_context.cc

Project Member

Comment 6 by bugdroid1@chromium.org, Oct 12 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/58cdcc5798f592aa748d73952b6fc785d7164666

commit 58cdcc5798f592aa748d73952b6fc785d7164666
Author: fdoray <fdoray@chromium.org>
Date: Wed Oct 12 12:13:00 2016

Remove MessageLoop::current() from socket_host_tcp.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2405273002
Cr-Commit-Position: refs/heads/master@{#424718}

[modify] https://crrev.com/58cdcc5798f592aa748d73952b6fc785d7164666/content/browser/renderer_host/p2p/socket_host_tcp.cc
[modify] https://crrev.com/58cdcc5798f592aa748d73952b6fc785d7164666/content/browser/renderer_host/p2p/socket_host_tcp.h

Project Member

Comment 7 by bugdroid1@chromium.org, Oct 12 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2111a57d06c915dce0a96bdfd2cffba284cf53c6

commit 2111a57d06c915dce0a96bdfd2cffba284cf53c6
Author: fdoray <fdoray@chromium.org>
Date: Wed Oct 12 21:27:50 2016

Remove MessageLoop::current() from ppapi/proxy.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2407393002
Cr-Commit-Position: refs/heads/master@{#424863}

[modify] https://crrev.com/2111a57d06c915dce0a96bdfd2cffba284cf53c6/ppapi/proxy/plugin_globals.cc
[modify] https://crrev.com/2111a57d06c915dce0a96bdfd2cffba284cf53c6/ppapi/proxy/proxy_completion_callback_factory.h

Project Member

Comment 8 by bugdroid1@chromium.org, Oct 13 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/571fada22bd532cb22a98ff61092026826deb98b

commit 571fada22bd532cb22a98ff61092026826deb98b
Author: fdoray <fdoray@chromium.org>
Date: Thu Oct 13 19:15:31 2016

Remove MessageLoop::current() from history_service.cc

Whenever possible, use Thread/SequencedTaskRunnerHandle::Get() instead
of MessageLoop::current(). Thread/SequencedTaskRunnerHandle::Get() work
within TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use Thread/SequencedTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use Thread/SequencedTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2406423003
Cr-Commit-Position: refs/heads/master@{#425121}

[modify] https://crrev.com/571fada22bd532cb22a98ff61092026826deb98b/components/history/core/browser/history_backend.cc
[modify] https://crrev.com/571fada22bd532cb22a98ff61092026826deb98b/components/history/core/browser/history_backend.h
[modify] https://crrev.com/571fada22bd532cb22a98ff61092026826deb98b/components/history/core/browser/history_service.cc

Project Member

Comment 9 by bugdroid1@chromium.org, Oct 13 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee2d4541810dee5db617b97be02b5a48f55143f4

commit ee2d4541810dee5db617b97be02b5a48f55143f4
Author: fdoray <fdoray@chromium.org>
Date: Thu Oct 13 20:21:08 2016

Remove MessageLoop::current() from stress_cache.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2410243002
Cr-Commit-Position: refs/heads/master@{#425141}

[modify] https://crrev.com/ee2d4541810dee5db617b97be02b5a48f55143f4/net/tools/stress_cache/stress_cache.cc

Project Member

Comment 10 by bugdroid1@chromium.org, Oct 13 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c6a29c14bcff7c8a8d2e6178ea684d50d82558b

commit 1c6a29c14bcff7c8a8d2e6178ea684d50d82558b
Author: fdoray <fdoray@chromium.org>
Date: Thu Oct 13 21:03:55 2016

Remove MessageLoop::current() from url_request.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2404313002
Cr-Commit-Position: refs/heads/master@{#425151}

[modify] https://crrev.com/1c6a29c14bcff7c8a8d2e6178ea684d50d82558b/net/url_request/url_request.cc

Project Member

Comment 11 by bugdroid1@chromium.org, Oct 14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8df1700462b359e414db9718d201cb3acb4e094e

commit 8df1700462b359e414db9718d201cb3acb4e094e
Author: fdoray <fdoray@chromium.org>
Date: Fri Oct 14 16:56:16 2016

Remove MessageLoop::current() from base_session_service.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2404353002
Cr-Commit-Position: refs/heads/master@{#425363}

[modify] https://crrev.com/8df1700462b359e414db9718d201cb3acb4e094e/components/sessions/core/base_session_service.cc

Project Member

Comment 12 by bugdroid1@chromium.org, Oct 17 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/db9773f332d38b31e03e154de919d4170463ab95

commit db9773f332d38b31e03e154de919d4170463ab95
Author: fdoray <fdoray@chromium.org>
Date: Mon Oct 17 23:26:34 2016

Remove MessageLoop::current() from demuxer_perftest.cc.

Whenever possible, use ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current(). ThreadTaskRunnerHandle::Get() works within
TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use ThreadTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use ThreadTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2404293003
Cr-Commit-Position: refs/heads/master@{#425809}

[modify] https://crrev.com/db9773f332d38b31e03e154de919d4170463ab95/media/base/demuxer_perftest.cc

Project Member

Comment 13 by bugdroid1@chromium.org, Oct 19 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0c755de5d020e417e439174144040713001f5c6b

commit 0c755de5d020e417e439174144040713001f5c6b
Author: fdoray <fdoray@chromium.org>
Date: Wed Oct 19 15:28:44 2016

Remove MessageLoop::current() from chrome_metrics_service_client.cc

Whenever possible, use Thread/SequencedTaskRunnerHandle::Get() instead
of MessageLoop::current(). Thread/SequencedTaskRunnerHandle::Get() work
within TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use Thread/SequencedTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use Thread/SequencedTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://chromiumcodereview.appspot.com/2412903002
Cr-Commit-Position: refs/heads/master@{#426200}

[modify] https://crrev.com/0c755de5d020e417e439174144040713001f5c6b/chrome/browser/metrics/chrome_metrics_service_client.cc
[modify] https://crrev.com/0c755de5d020e417e439174144040713001f5c6b/content/browser/histogram_synchronizer.cc
[modify] https://crrev.com/0c755de5d020e417e439174144040713001f5c6b/content/browser/histogram_synchronizer.h
[modify] https://crrev.com/0c755de5d020e417e439174144040713001f5c6b/content/public/browser/histogram_fetcher.h
[modify] https://crrev.com/0c755de5d020e417e439174144040713001f5c6b/content/public/test/browser_test_utils.cc

Project Member

Comment 14 by bugdroid1@chromium.org, Oct 20 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5686c9eb004698df3b62f4e3d63e1ceaca0eff4e

commit 5686c9eb004698df3b62f4e3d63e1ceaca0eff4e
Author: fdoray <fdoray@chromium.org>
Date: Thu Oct 20 14:35:42 2016

Remove MessageLoop::current() from history_url_provider.cc

Whenever possible, use Thread/SequencedTaskRunnerHandle::Get() instead
of MessageLoop::current(). Thread/SequencedTaskRunnerHandle::Get() work
within TaskScheduler while MessageLoop::current() doesn't.

Good reasons to use MessageLoop::current():
- Add destruction, nesting or task observers.
- Run nested loops.

Bad reasons to use MessageLoop::current():
- Post tasks. Use Thread/SequencedTaskRunnerHandle::Get() instead.
- Watch a file descriptor. Use FileDescriptorWatcher instead.
- Verify that it is possible to post tasks to the current thread.
  Use Thread/SequencedTaskRunnerHandle::IsSet() instead.
- Verify that code runs on a specific thread. Use
  SingleThreadTaskRunner::BelongsToCurrentThread() instead.

BUG= 650723 

Review-Url: https://chromiumcodereview.appspot.com/2409083003
Cr-Commit-Position: refs/heads/master@{#426474}

[modify] https://crrev.com/5686c9eb004698df3b62f4e3d63e1ceaca0eff4e/components/omnibox/browser/history_url_provider.cc
[modify] https://crrev.com/5686c9eb004698df3b62f4e3d63e1ceaca0eff4e/components/omnibox/browser/history_url_provider.h

Comment 15 Deleted

Status: Started (was: Fixed)
To my knowledge, no MessageLoop::current() calls remain in production code on browser threads that will be redirected to TaskScheduler (except to add destruction observers - this is addressed in a separate bug  https://crbug.com/650318 ).

Some calls may remain in browser tests.
Project Member

Comment 17 by bugdroid1@chromium.org, Nov 4 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/119462f5be2cba878cf3d30142411a06868ed464

commit 119462f5be2cba878cf3d30142411a06868ed464
Author: fdoray <fdoray@chromium.org>
Date: Fri Nov 04 20:17:00 2016

Remove ModelSafeWorker::work_done_or_stopped().

BrowserThreads will be migrated to TaskScheduler which doesn't support
destruction observers. This CL removes an event signaled after a task
runs or from ModelSafeWorker::WillDestroyCurrentMessageLoop() with an
event signaled after a task runs or after it is deleted (MessageLoop
deletes pending tasks in its destructor).

BUG= 650723 

Review-Url: https://codereview.chromium.org/2466313003
Cr-Commit-Position: refs/heads/master@{#429994}

[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/history/core/browser/history_model_worker.cc
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/password_manager/sync/browser/password_model_worker.cc
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/password_manager/sync/browser/password_model_worker.h
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/BUILD.gn
[add] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/base/scoped_event_signal.cc
[add] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/base/scoped_event_signal.h
[add] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/base/scoped_event_signal_unittest.cc
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/driver/glue/browser_thread_model_worker.cc
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/driver/glue/browser_thread_model_worker.h
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/driver/glue/ui_model_worker.cc
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/engine/model_safe_worker.cc
[modify] https://crrev.com/119462f5be2cba878cf3d30142411a06868ed464/components/sync/engine/model_safe_worker.h

Project Member

Comment 18 by bugdroid1@chromium.org, Nov 7 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2

commit ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2
Author: fdoray <fdoray@chromium.org>
Date: Mon Nov 07 16:35:08 2016

Do not observe MessageLoop destruction from ModelSafeWorker.

BrowserThreads are being migrated to TaskScheduler which doesn't
support MessageLoop destruction observers. Destruction observers
currently serve two purposes in ModelSafeWorker:

1. Set a "stopped" flag to true. When this flag is true,
DoWorkAndWaitUntilDone() returns CANNOT_DO_WORK immediately.

-> This is useless because all DoWorkAndWaitUntilDoneImpl()
   implementations already return CANNOT_DO_WORK when they
   are unable to schedule a task.

   For example, in
   BrowserThreadModelWorker::DoWorkAndWaitUntilDoneImpl():

    // Note: PostTask returns false once the MessageLoop
    // running on the BrowserThread is destroyed.
    if (!runner_->PostTask(
            FROM_HERE,
            base::Bind(...))) {
      DLOG(WARNING) << "Failed to post task to runner " << runner_;
      error = CANNOT_DO_WORK;
      return error;
    }

2. Notify SyncBackendRegistrar that the MessageLoop was
   destroyed so that it can move the ModelSafeWorker to an
   inactive list. When all ModelSafeWorkers have been moved to
   the inactive list, SyncBackendRegistrar deletes itself.

-> There is no reason to keep SyncBackendRegistrar alive
   after both SyncManager and SyncBackendHostImpl have cleared
   their pointer/unique_ptr to it. With this CL,
   SyncBackendRegistrar is deleted by a DeleteSoon task posted
   from SyncBackendHostImpl::Shutdown().

-> Deleting SyncBackendRegistrar causes the ModelSafeWorker
   references kept in |stopped_workers_| to be released. This
   is not dangerous since any object that still needs to use
   a ModelSafeWorker should have its own reference to it.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2471183003
Cr-Commit-Position: refs/heads/master@{#430293}

[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/chrome/browser/sync/chrome_sync_client.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/chrome/browser/sync/chrome_sync_client.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/browser_sync/profile_sync_test_util.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/history/core/browser/history_model_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/history/core/browser/history_model_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/password_manager/sync/browser/password_model_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/password_manager/sync/browser/password_model_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/fake_sync_client.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/fake_sync_client.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/browser_thread_model_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/browser_thread_model_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/browser_thread_model_worker_unittest.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/sync_backend_host.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/sync_backend_host_impl.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/sync_backend_host_impl_unittest.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/sync_backend_registrar.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/sync_backend_registrar.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/sync_backend_registrar_unittest.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/ui_model_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/ui_model_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/glue/ui_model_worker_unittest.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/driver/sync_client.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/engine/model_safe_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/engine/model_safe_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/engine/passive_model_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/engine/passive_model_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/test/engine/fake_model_worker.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/test/engine/fake_model_worker.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/components/sync/tools/sync_client.cc
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/ios/chrome/browser/sync/ios_chrome_sync_client.h
[modify] https://crrev.com/ea7a7eca75b39bfc9cbf72aed8a4dffa1d77f1e2/ios/chrome/browser/sync/ios_chrome_sync_client.mm

Comment 19 by gab@chromium.org, Nov 7 2016

Components: Internals>TaskScheduler
Project Member

Comment 20 by bugdroid1@chromium.org, Nov 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3b9a7a6338f1c5f393d2201f16839eb072d3c277

commit 3b9a7a6338f1c5f393d2201f16839eb072d3c277
Author: fdoray <fdoray@chromium.org>
Date: Fri Nov 11 15:31:16 2016

Remove DeviceMonitorLinux::WillDestroyCurrentMessageLoop().

The FILE thread will soon be migrated to TaskScheduler which doesn't
support MessageLoop destruction observers.

DeviceMonitorLinux::WillDestroyCurrentMessageLoop() notified 3 observers
that the DeviceMonitorLinux MessageLoop was being destroyed. Each
observer used this notification to destroy itself.

- InputServiceLinuxImpl: This is now a leaky LazyInstance which is
  never destroyed.
- HidServiceLinux::FileThreadHelper: This is now destroyed by posting
  a delete task to the FILE thread when HidServiceLinux::Shutdown is
  called. HidServiceLinux::Shutdown is called from
  BrowserProcessImpl::StartTearDown() which is called before the
  FILE thread is teared down.
- UsbServiceLinux::FileThreadHelper: Same pattern as
  HidServiceLinux::FileThreadHelper.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2482463002
Cr-Commit-Position: refs/heads/master@{#431564}

[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/chrome/browser/browser_process_impl.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/chrome/browser/chrome_device_client.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/chrome/browser/chrome_device_client.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/chrome/browser/chromeos/device/input_service_test_helper.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/chrome/browser/chromeos/login/hid_detection_browsertest.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/base/device_monitor_linux.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/base/device_monitor_linux.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/hid_service.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/hid_service.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/hid_service_linux.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/hid_service_linux.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/input_service_linux.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/input_service_linux.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/hid/mock_hid_service.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/test/test_device_client.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/test/test_device_client.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/usb/mock_usb_service.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/usb/usb_service.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/usb/usb_service.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/usb/usb_service_linux.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/device/usb/usb_service_linux.h
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/extensions/shell/browser/shell_browser_main_parts.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/extensions/shell/browser/shell_device_client.cc
[modify] https://crrev.com/3b9a7a6338f1c5f393d2201f16839eb072d3c277/extensions/shell/browser/shell_device_client.h

Project Member

Comment 21 by bugdroid1@chromium.org, Nov 14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0

commit 1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0
Author: fdoray <fdoray@chromium.org>
Date: Mon Nov 14 22:37:55 2016

Require FilePathWatcher destructor to be called in sequence with Watch().

file_path_watcher_win.cc and file_path_watcher_kqueue.cc need to do
some cleanup on the sequence from which Watch() is called. They use
destruction observers to do this cleanup when the MessageLoop from
which Watch() is called is destroyed (after that, it is too late to
post tasks to the MessageLoop sequence).

With this CL, the FilePathWatcher destructor must be called on the
sequence from which Watch() is called. That means that will be able
to move the work done in MessageLoop destruction observers to the
FilePathWatcher destructor. Getting rid of destruction observers in
FilePathWatcher is important because they are not supported in
TaskScheduler.

TBR=scottbyer@chromium.org
BUG= 650723 

Review-Url: https://codereview.chromium.org/2438913003
Cr-Commit-Position: refs/heads/master@{#431921}

[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher.h
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher_linux.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher_mac.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher_stub.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher_unittest.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/base/files/file_path_watcher_win.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/browser/media_galleries/fileapi/file_path_watcher_util.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/browser/media_galleries/fileapi/file_path_watcher_util.h
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/browser/media_galleries/fileapi/iapps_data_provider.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/browser/media_galleries/fileapi/itunes_file_util_unittest.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/browser/media_galleries/fileapi/picasa_data_provider.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/common/service_process_util.h
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/common/service_process_util_posix.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/common/service_process_util_posix.h
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/common/service_process_util_win.cc
[modify] https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0/chrome/service/service_process.cc

Project Member

Comment 22 by bugdroid1@chromium.org, Nov 23 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ee0332133b606f70eadecdbf420e3afe9778055

commit 9ee0332133b606f70eadecdbf420e3afe9778055
Author: fdoray <fdoray@chromium.org>
Date: Wed Nov 23 18:29:29 2016

Stop checking that FilePathWatcher is used from a MessageLoopForIO.

No FilePathWatcher implementation requires to be used from a
MessageLoopForIO.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2516353003
Cr-Commit-Position: refs/heads/master@{#434205}

[modify] https://crrev.com/9ee0332133b606f70eadecdbf420e3afe9778055/base/files/file_path_watcher_fsevents.cc
[modify] https://crrev.com/9ee0332133b606f70eadecdbf420e3afe9778055/base/files/file_path_watcher_linux.cc

Status: Fixed (was: Started)
Project Member

Comment 24 by bugdroid1@chromium.org, Apr 5 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/56564d4099ebbaecf1cfb804cc09a6d198101fbb

commit 56564d4099ebbaecf1cfb804cc09a6d198101fbb
Author: reillyg <reillyg@chromium.org>
Date: Wed Apr 05 02:59:17 2017

Remove MessageLoop destruction observer from //device/usb

This patch updates UsbDeviceHandleUsbfs::FileThreadHelper to no longer
be a MessageLoop::DestructionObserver and instead ensures that
UsbService::ShutDown will close all open connections, destroying the
FILE thread state.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2797433005
Cr-Commit-Position: refs/heads/master@{#461960}

[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_device_handle_android.cc
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_device_handle_usbfs.cc
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_device_handle_usbfs.h
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_service.cc
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_service_unittest.cc

Project Member

Comment 25 by bugdroid1@chromium.org, Apr 8 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6a2cc0923f353e6ab781ba7ef21b664106145c1a

commit 6a2cc0923f353e6ab781ba7ef21b664106145c1a
Author: reillyg <reillyg@chromium.org>
Date: Sat Apr 08 01:44:34 2017

Remove MessageLoop destruction observer from hid_connection_linux.cc

This patch makes HidConnectionLinux::FileThreadHelper to no longer a
MessageLoop::DestructionObserver and cleans up ownership of the device
file descriptor.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2799743006
Cr-Commit-Position: refs/heads/master@{#463103}

[modify] https://crrev.com/6a2cc0923f353e6ab781ba7ef21b664106145c1a/device/hid/hid_connection_linux.cc
[modify] https://crrev.com/6a2cc0923f353e6ab781ba7ef21b664106145c1a/device/hid/hid_connection_linux.h
[modify] https://crrev.com/6a2cc0923f353e6ab781ba7ef21b664106145c1a/device/hid/hid_service_linux.cc
[modify] https://crrev.com/6a2cc0923f353e6ab781ba7ef21b664106145c1a/device/hid/hid_service_linux.h

Project Member

Comment 26 by bugdroid1@chromium.org, Apr 10 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2cd83da8d67df6634cb770c559f7e588b5ae25b5

commit 2cd83da8d67df6634cb770c559f7e588b5ae25b5
Author: reillyg <reillyg@chromium.org>
Date: Mon Apr 10 16:08:54 2017

Remove MessageLoop destruction observer from hid_connection_win.cc

PendingHidTransfer does not need to be a MessageLoop destruction
observer because these objects live on the main thread and are freed
synchronously when the HidConnectionWin is closed.

BUG= 650723 

Review-Url: https://codereview.chromium.org/2802093009
Cr-Commit-Position: refs/heads/master@{#463283}

[modify] https://crrev.com/2cd83da8d67df6634cb770c559f7e588b5ae25b5/device/hid/hid_connection_win.cc

Comment 27 by gab@chromium.org, Mar 23 2018

Blocking: 825327

Sign in to add a comment