diff options
author | rockot <rockot@chromium.org> | 2016-03-14 22:57:59 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2016-03-15 05:59:39 +0000 |
commit | 27eb4409b17331235123e5e0a6837aa760203816 (patch) | |
tree | 1b6c8683bf086786b24428e0f7ab7d57aedb5f22 /ui/gl | |
parent | 7bdeb45f2e1c8b2bf9601cd3893946435bc30ae1 (diff) | |
download | chromium_src-27eb4409b17331235123e5e0a6837aa760203816.zip chromium_src-27eb4409b17331235123e5e0a6837aa760203816.tar.gz chromium_src-27eb4409b17331235123e5e0a6837aa760203816.tar.bz2 |
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.
Review URL: https://codereview.chromium.org/1797153002
Cr-Commit-Position: refs/heads/master@{#381182}
Diffstat (limited to 'ui/gl')
0 files changed, 0 insertions, 0 deletions