Reinstate wait-for-Initialize when Chrome is run in Mash

Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a temporary switch
to explicitly opt in to wait-for-Initialize behavior on
MojoShellConnection, and adds that switch when running in mash.

BUG=594636, 594852
TEST=views_mus_unittests, mus_ws_unittests, and chrome --mash renders as well as it did before I broke it.

Committed: https://crrev.com/27eb4409b17331235123e5e0a6837aa760203816
Cr-Commit-Position: refs/heads/master@{#381182}

[Ken Rockot(use gerrit already), 2016-03-15 01:24:45]

Description was changed from

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

This adds a switch to explicitly opt-in to wait-for-Initialize,
and adds that switch when running in mash.

BUG=594636,594852
==========

to

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a switch to explicitly
opt-in to wait-for-Initialize, and adds that switch when
running in mash.

BUG=594636,594852
==========

[Ken Rockot(use gerrit already), 2016-03-15 01:25:21]

Description was changed from

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a switch to explicitly
opt-in to wait-for-Initialize, and adds that switch when
running in mash.

BUG=594636,594852
==========

to

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a temporary switch
to explicitly opt in to wait-for-Initialize behavior on
MojoShellConnection, and adds that switch when running in mash.

BUG=594636,594852
==========

[Ken Rockot(use gerrit already), 2016-03-15 02:18:19]

Description was changed from

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a temporary switch
to explicitly opt in to wait-for-Initialize behavior on
MojoShellConnection, and adds that switch when running in mash.

BUG=594636,594852
==========

to

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a temporary switch
to explicitly opt in to wait-for-Initialize behavior on
MojoShellConnection, and adds that switch when running in mash.

BUG=594636,594852
TEST=views_mus_unittests, mus_ws_unittests, and chrome --mash renders as well as
it did before I broke it.
==========

[Ken Rockot(use gerrit already), 2016-03-15 02:18:35]

rockot@chromium.org changed reviewers:
+ ben@chromium.org

[Ken Rockot(use gerrit already), 2016-03-15 02:18:35]

doh

[Ben Goodger (Google), 2016-03-15 02:28:12]

lgtm

[Ken Rockot(use gerrit already), 2016-03-15 04:49:07]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2016-03-15 04:49:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1797153002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1797153002/20001

[commit-bot: I haz the power, 2016-03-15 05:58:09]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-03-15 05:59:47]

Description was changed from

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a temporary switch
to explicitly opt in to wait-for-Initialize behavior on
MojoShellConnection, and adds that switch when running in mash.

BUG=594636,594852
TEST=views_mus_unittests, mus_ws_unittests, and chrome --mash renders as well as
it did before I broke it.
==========

to

==========
Reinstate wait-for-Initialize when Chrome is run in Mash

Mus Views needs to completely block the main thread during
initialization, including any pending tasks. This means
incoming messages on any other pipe will never be dispatched.
If ShellClient::Initialize is blocked, the pipe views is
waiting on will in turn never be able to signal, resulting
in an effective deadlock.

So we need to wait for Initialize before proceeding with the
rest of the main thread setup. This adds a temporary switch
to explicitly opt in to wait-for-Initialize behavior on
MojoShellConnection, and adds that switch when running in mash.

BUG=594636,594852
TEST=views_mus_unittests, mus_ws_unittests, and chrome --mash renders as well as
it did before I broke it.

Committed: https://crrev.com/27eb4409b17331235123e5e0a6837aa760203816
Cr-Commit-Position: refs/heads/master@{#381182}
==========

[commit-bot: I haz the power, 2016-03-15 05:59:48]

Patchset 2 (id:??) landed as
https://crrev.com/27eb4409b17331235123e5e0a6837aa760203816
Cr-Commit-Position: refs/heads/master@{#381182}