mus/chrome: Always wait for the mojo shell.

content/common/mojo/mojo_shell_connection_impl.cc

 // Copyright 2015 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 "content/common/mojo/mojo_shell_connection_impl.h"
 
 #include <utility>
 
 #include "base/command_line.h"
 #include "base/lazy_instance.h"
@@ skipping 22 matching lines @@
 
 }  // namespace
 
 bool IsRunningInMojoShell() {
   return mojo_shell_connection_factory ||
          base::CommandLine::ForCurrentProcess()->HasSwitch(
              mojo::edk::PlatformChannelPair::kMojoPlatformChannelHandleSwitch);
 }
 
 bool ShouldWaitForShell() {
-  return mojo_shell_connection_factory ||
-         (IsRunningInMojoShell() &&
-          base::CommandLine::ForCurrentProcess()->HasSwitch(
-              switches::kWaitForMojoShell));
+  return mojo_shell_connection_factory || IsRunningInMojoShell();

[Ken Rockot(use gerrit already), 2016/04/25 23:29:35]

Unfortunately IsRunningInMojoShell is a misnomer, as it looks for a flag which
is used for reasons other than running in Mojo shell. For example, content child
processes get this flag set by the browser process when launched. It should
really be called HasShellClientRequestOnCommandLine or something.

We do not want content child processes waiting for the Mojo shell. We need some
other way to detect if we're running in an external shell, and that's what
--wait-for-mojo-shell was for. Can we somehow force this flag to be present in
the cases we care about?

[sadrul, 2016/04/26 03:22:04]

I was thinking a naive workaround would be to check for the process-type as well
... but I have done things a bit differently in the latest patchset: from
reading https://crrev.com/381182, it sounds like we need to wait for the
initialization only because of how we initialize views
(views::WindowManagerConnection, which initializes views::ScreenMus, which does
another blocking call to mojo:mus), and so I moved the 'wait for initialization'
in the same place where we create this views::WindowManagerConnection object, in
BrowserMainLoop (just before WindowManagerConnection is creted). This means none
of the child processes ever block, and the browser process only blocks when
running inside of mus. I think this takes care of the concerns? (if not, I will
add the cmd-flag explicitly in the test and other such cases where we need to,
but I thought I would give this one more try)

 }
 
 // static
 bool MojoShellConnectionImpl::CreateUsingFactory() {
   if (mojo_shell_connection_factory) {
     DCHECK(!lazy_tls_ptr.Pointer()->Get());
     mojo_shell_connection_factory->Run();
     DCHECK(lazy_tls_ptr.Pointer()->Get());
     return true;
   }
@@ skipping 109 matching lines @@
 // static
 void MojoShellConnection::Destroy() {
   // This joins the shell controller thread.
   delete Get();
   lazy_tls_ptr.Pointer()->Set(nullptr);
 }
 
 MojoShellConnection::~MojoShellConnection() {}
 
 }  // namespace content