Move Mus into chrome's process when running with --mus.

services/ui/ws/threaded_image_cursors.cc

Index: services/ui/ws/threaded_image_cursors.cc
diff --git a/services/ui/ws/threaded_image_cursors.cc b/services/ui/ws/threaded_image_cursors.cc
new file mode 100644
index 0000000000000000000000000000000000000000..3f1fb3715d304f2ad2c6417d809dc473498c69e3
--- /dev/null
+++ b/services/ui/ws/threaded_image_cursors.cc
@@ -0,0 +1,58 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "services/ui/ws/threaded_image_cursors.h"
+#include "base/bind.h"
+#include "base/single_thread_task_runner.h"
+#include "ui/platform_window/platform_window.h"
+
+namespace ui {
+namespace ws {
+
+ThreadedImageCursors::ThreadedImageCursors(
+    scoped_refptr<base::SingleThreadTaskRunner>& task_runner)
+    : task_runner_(task_runner), weak_ptr_factory_(this) {
+  DCHECK(task_runner_);
+}
+
+ThreadedImageCursors::~ThreadedImageCursors() {}
+
+void ThreadedImageCursors::SetDisplay(const display::Display& display,
+                                      float scale_factor) {
+  if (task_runner_) {

[sky, 2017/06/20 22:33:13]

WDYT of *always* using a task runner? I realize it's unnecessary in the
non-in-process case, but it would mean far less conditionals like this.

[mfomitchev, 2017/06/21 21:22:51]

Done.

+    task_runner_->PostTask(
+        FROM_HERE,
+        base::Bind(&ThreadedImageCursors::SetDisplaySync,
+                   weak_ptr_factory_.GetWeakPtr(), display, scale_factor));
+  } else {
+    SetDisplaySync(display, scale_factor);
+  }
+}
+
+void ThreadedImageCursors::SetCursor(ui::CursorType cursor_type,
+                                     ui::PlatformWindow* platform_window) {
+  if (task_runner_) {
+    task_runner_->PostTask(
+        FROM_HERE, base::Bind(&ThreadedImageCursors::SetCursorSync,
+                              weak_ptr_factory_.GetWeakPtr(), cursor_type,
+                              platform_window));
+  } else {
+    SetCursorSync(cursor_type, platform_window);
+  }
+}
+
+void ThreadedImageCursors::SetDisplaySync(const display::Display& display,
+                                          float scale_factor) {
+  image_cursors_.SetDisplay(display, scale_factor);
+}
+
+void ThreadedImageCursors::SetCursorSync(ui::CursorType cursor_type,
+                                         ui::PlatformWindow* platform_window) {

[sky, 2017/06/20 22:33:13]

How do you know platformwindow is still valid by the time you get here?

[mfomitchev, 2017/06/21 21:22:51]

Sigh.

Ok, so platform_window_ will outlive ThreadedImageCursors. This is because both
are owned by PlatformDisplayDefault, and platform_window_ is only reset in
PlatformDisplayDefault's destructor, and that's done after image_cursors_ is
reset.

However, there is a thread safety issue with ThreadedImageCursors itself: we
shouldn't access its internal state (image_cursors_) on the browser UI thread,
because it is getting destroyed on the WS thread. It looks like this would only
happen at shutdown, but still..

I've fixed this by moving the ownership of image_cursors_ to the UI thread (I've
put it in ChromeContentBrowserClient, which also creates the ui::Service, there
may be a better place for it). This makes the code more complex though. Please
take another look, and let me know what you think.

+  ui::Cursor native_cursor(cursor_type);
+  image_cursors_.SetPlatformCursor(&native_cursor);
+  platform_window->SetCursor(native_cursor.platform());
+}
+
+}  // namesapce ws
+}  // namesapce ui