Move content's shell connections to the IO thread

Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398, 612500, 619202
Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Committed: https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Committed: https://crrev.com/cef3827ff96c4fa12fcfbe95942f5d1b0a512a08
Cr-Original-Original-Commit-Position: refs/heads/master@{#404228}
Cr-Original-Commit-Position: refs/heads/master@{#404556}
Cr-Commit-Position: refs/heads/master@{#405885}

[Ken Rockot(use gerrit already), 2016-07-02 17:47:11]

Description was changed from

==========
[WIP] Move content shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the MojoShell/ChildConnection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=619202
==========

to

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=619202
==========

[Ken Rockot(use gerrit already), 2016-07-02 17:47:11]

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

[Ken Rockot(use gerrit already), 2016-07-02 17:50:25]

It's not quite done, I still have to update callers of AddEmbeddedShellClient to
use AddConnectionFilter (forces users to reason about threading and lifetime),
and I'm not sure if that will even feel right. But this covers the basic idea.

Also note my fix for GetConnectorForIOThread, which we could probably extract
and commit separately: no need for thread-local storage or setting it async. It
can just be a lazy unique_ptr, and it can be set directly from the
MojoShellContext constructor. It is only bound to the thread which first uses
it. Only IO-thread tasks will use it, and only after the MojoShellContext
constructor has run.

[Ben Goodger (Google), 2016-07-02 18:05:48]

Sweet! Have to run some errands now, will take a look this afternoon during
nap time.

-Ben

On Sat, Jul 2, 2016 at 10:50 AM, <rockot@chromium.org> wrote:

> Reviewers: Ben Goodger (Google)
> CL: https://codereview.chromium.org/2111353002/
>
> Message:
> It's not quite done, I still have to update callers of
> AddEmbeddedShellClient to
> use AddConnectionFilter (forces users to reason about threading and
> lifetime),
> and I'm not sure if that will even feel right. But this covers the basic
> idea.
>
> Also note my fix for GetConnectorForIOThread, which we could probably
> extract
> and commit separately: no need for thread-local storage or setting it
> async. It
> can just be a lazy unique_ptr, and it can be set directly from the
> MojoShellContext constructor. It is only bound to the thread which first
> uses
> it. Only IO-thread tasks will use it, and only after the MojoShellContext
> constructor has run.
>
> Description:
> Move content's shell connections to the IO thread
>
> Moves all shell connections in the content layer
> (connections owned by instances of MojoShellConnection and
> MojoChildConnection) to the IO thread in all process types.
> Note that instances of MojoShellConnection and
> MojoChildConnection may still be created and used on
> any thread.
>
> Additionally exposes a way for InterfaceRegistry and
> InterfaceProvider to forward to/from other instances
> so we can still have a corresponding instance of each
> on whatever thread owns the Mojo[Shell/Child]Connection
> object.
>
> This simplifies interface registration and acquisition
> on process hosts and ChildThreadImpls, and makes it possible
> for a future CL to introduce IO-thread service registration
> to avoid thread hops when binding incoming interface requests.
>
> BUG=619202
>
> Base URL: https://chromium.googlesource.com/chromium/src.git@master
>
> Affected files (+649, -335 lines):
> M chrome/test/base/mash_browser_tests_main.cc
> M content/browser/browser_context.cc
> M content/browser/browser_main_loop.cc
> M content/browser/gpu/gpu_process_host.cc
> M content/browser/mojo/mojo_child_connection.h
> M content/browser/mojo/mojo_child_connection.cc
> M content/browser/mojo/mojo_shell_context.cc
> M content/browser/renderer_host/render_process_host_impl.h
> M content/browser/renderer_host/render_process_host_impl.cc
> M content/browser/renderer_host/render_widget_host_view_mus.cc
> M content/browser/utility_process_host_impl.cc
> M content/child/background_sync/background_sync_provider.cc
> M content/child/child_thread_impl.h
> M content/child/child_thread_impl.cc
> M content/common/mojo/mojo_shell_connection_impl.h
> M content/common/mojo/mojo_shell_connection_impl.cc
> M content/gpu/gpu_child_thread.h
> M content/gpu/gpu_child_thread.cc
> M content/public/browser/render_process_host.h
> M content/public/common/mojo_shell_connection.h
> M content/public/test/mock_render_process_host.h
> M content/public/test/mock_render_process_host.cc
> M content/renderer/render_thread_impl.cc
> M content/renderer/renderer_blink_platform_impl.cc
> M content/renderer/service_worker/service_worker_context_client.cc
> M services/shell/public/cpp/connector.h
> M services/shell/public/cpp/interface_provider.h
> M services/shell/public/cpp/interface_registry.h
> M services/shell/public/cpp/lib/connector_impl.h
> M services/shell/public/cpp/lib/connector_impl.cc
> M services/shell/public/cpp/lib/interface_provider.cc
> M services/shell/public/cpp/lib/interface_registry.cc
> M services/shell/public/cpp/lib/shell_connection.cc
> M services/shell/public/cpp/shell_connection.h
>
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ben Goodger (Google), 2016-07-03 03:29:27]

https://codereview.chromium.org/2111353002/diff/20001/content/common/mojo/moj...
File content/common/mojo/mojo_shell_connection_impl.cc (right):

https://codereview.chromium.org/2111353002/diff/20001/content/common/mojo/moj...
content/common/mojo/mojo_shell_connection_impl.cc:284: const ConnectionFilter&
filter) {
did you mean to leave this implementation empty?

https://codereview.chromium.org/2111353002/diff/20001/content/gpu/gpu_child_t...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/2111353002/diff/20001/content/gpu/gpu_child_t...
content/gpu/gpu_child_thread.cc:225: // Use of base::Unretained(this) is safe
here because |service_registry()|
This seems worse than before - given that you don't have the ability to inspect
the incoming connection before you expose interfaces?

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

Patchset #3 (id:40001) has been deleted

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

Patchset #3 (id:60001) has been deleted

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

Patchset #3 (id:80001) has been deleted

[Ken Rockot(use gerrit already), 2016-07-04 18:22:58]

Moar changes.

One outstanding problem is that this exposed a racy deadlock. We're apparently
using sync mojo messages from blink already, and I'm not sure that's OK to do
yet since legacy IPC can't wake up a sync mojo wait. Looking into it.

https://codereview.chromium.org/2111353002/diff/20001/content/gpu/gpu_child_t...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/2111353002/diff/20001/content/gpu/gpu_child_t...
content/gpu/gpu_child_thread.cc:225: // Use of base::Unretained(this) is safe
here because |service_registry()|
On 2016/07/03 at 03:29:27, Ben Goodger (Google) wrote:
> This seems worse than before - given that you don't have the ability to
inspect the incoming connection before you expose interfaces?

Right, so it's not really worse in practice since these interfaces weren't
filtered based on any property of the incoming connection. This isn't what
interface registration should look like, but currently all interface
registration is expected to happen on the main thread, and this CL has to move
the relevant shell::Connections to the IO thread. AcceptConnection can't do its
work asynchronously or it would race with incoming connections. Also this part
of the CL wasn't complete when I sent it out.

Now I've changed ProcessControl exposure to be done via a ConnectionFilter which
lives on the IO thread.

It's necessary to have ConnectionFilters live on the IO thread, but it's also
super awkward when they want to register interfaces that should be bound on the
main thread. I would like to devise some reusable helpers for this, but since
there are only a handful of cases that exist today, I've opted to roll one-off
solutions for this CL (see ChromeInterfaceRegistry and
RenderWidgetWindowTreeClientWhateverRidiculousName for examples.)

[Ken Rockot(use gerrit already), 2016-07-04 18:26:47]

On 2016/07/04 at 18:22:58, Ken Rockot wrote:
> Moar changes.
> 
> One outstanding problem is that this exposed a racy deadlock. We're apparently
using sync mojo messages from blink already, and I'm not sure that's OK to do
yet since legacy IPC can't wake up a sync mojo wait. Looking into it.
> 
>
https://codereview.chromium.org/2111353002/diff/20001/content/gpu/gpu_child_t...
> File content/gpu/gpu_child_thread.cc (right):
> 
>
https://codereview.chromium.org/2111353002/diff/20001/content/gpu/gpu_child_t...
> content/gpu/gpu_child_thread.cc:225: // Use of base::Unretained(this) is safe
here because |service_registry()|
> On 2016/07/03 at 03:29:27, Ben Goodger (Google) wrote:
> > This seems worse than before - given that you don't have the ability to
inspect the incoming connection before you expose interfaces?
> 
> Right, so it's not really worse in practice since these interfaces weren't
filtered based on any property of the incoming connection. This isn't what
interface registration should look like, but currently all interface
registration is expected to happen on the main thread, and this CL has to move
the relevant shell::Connections to the IO thread. AcceptConnection can't do its
work asynchronously or it would race with incoming connections. Also this part
of the CL wasn't complete when I sent it out.

Clarification: it would race with incoming interface requests on that
connection.

> 
> Now I've changed ProcessControl exposure to be done via a ConnectionFilter
which lives on the IO thread.
> 
> It's necessary to have ConnectionFilters live on the IO thread, but it's also
super awkward when they want to register interfaces that should be bound on the
main thread. I would like to devise some reusable helpers for this, but since
there are only a handful of cases that exist today, I've opted to roll one-off
solutions for this CL (see ChromeInterfaceRegistry and
RenderWidgetWindowTreeClientWhateverRidiculousName for examples.)

ChromeInterfaceFactory*

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

OK, deadlock should be fixed.

[Ken Rockot(use gerrit already), 2016-07-05 21:02:24]

Description was changed from

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=619202
==========

to

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398
==========

[Ken Rockot(use gerrit already), 2016-07-05 21:02:32]

Description was changed from

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398
==========

to

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500
==========

[Ben Goodger (Google), 2016-07-05 21:39:45]

OK I still feel a bit queasy about all this but since I'm on vacation, it seems
to work, and I think fixes some crash bugs I have, I'll bite.

lgtm

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
File chrome/browser/chromeos/chrome_interface_factory.cc (right):

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
chrome/browser/chromeos/chrome_interface_factory.cc:155:
FactoryImpl::AddFactory<keyboard::mojom::Keyboard>(connection,
my eye is telling me you should wrap these like the last two invocations for
consistency

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
File chrome/browser/chromeos/chrome_interface_factory.h (right):

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
chrome/browser/chromeos/chrome_interface_factory.h:23: bool
AcceptConnection(shell::Connection* connection,
OnConnect, now.

[Ken Rockot(use gerrit already), 2016-07-06 17:09:57]

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
File chrome/browser/chromeos/chrome_interface_factory.cc (right):

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
chrome/browser/chromeos/chrome_interface_factory.cc:155:
FactoryImpl::AddFactory<keyboard::mojom::Keyboard>(connection,
On 2016/07/05 at 21:39:45, Ben Goodger (Google) wrote:
> my eye is telling me you should wrap these like the last two invocations for
consistency

I agree, but this is the work of clang_format. I've wrapped them and ignored the
formatting warning now. I don't think it'll be blocked by presubmit.

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
File chrome/browser/chromeos/chrome_interface_factory.h (right):

https://codereview.chromium.org/2111353002/diff/200001/chrome/browser/chromeo...
chrome/browser/chromeos/chrome_interface_factory.h:23: bool
AcceptConnection(shell::Connection* connection,
On 2016/07/05 at 21:39:45, Ben Goodger (Google) wrote:
> OnConnect, now.

done

[Ken Rockot(use gerrit already), 2016-07-07 17:16:05]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-07-07 17:16:06]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org
Link to the patchset: https://codereview.chromium.org/2111353002/#ps220001
(title: "AcceptConnection -> OnConnect")

[commit-bot: I haz the power, 2016-07-07 17:16:37]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-07 18:10:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-07 18:10:44]

Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[Ken Rockot(use gerrit already), 2016-07-07 19:59:05]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2016-07-07 19:59:38]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-07 20:19:31]

Committed patchset #9 (id:220001)

[commit-bot: I haz the power, 2016-07-07 20:19:35]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-07 20:21:00]

Description was changed from

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500
==========

to

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Cr-Commit-Position: refs/heads/master@{#404228}
==========

[commit-bot: I haz the power, 2016-07-07 20:21:01]

Patchset 9 (id:??) landed as
https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Cr-Commit-Position: refs/heads/master@{#404228}

[Ken Rockot(use gerrit already), 2016-07-07 20:47:56]

A revert of this CL (patchset #9 id:220001) has been created in
https://codereview.chromium.org/2132793002/ by rockot@chromium.org.

The reason for reverting is: stupid build failure.

[Ken Rockot(use gerrit already), 2016-07-07 21:06:44]

Relanding with compile fix

[Ken Rockot(use gerrit already), 2016-07-07 21:06:46]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-07-07 21:06:47]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org
Link to the patchset: https://codereview.chromium.org/2111353002/#ps240001
(title: ".")

[commit-bot: I haz the power, 2016-07-07 21:07:54]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-07 23:09:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-07 23:09:47]

Try jobs failed on following builders:
  mac_chromium_gyp_rel on master.tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)

[Ken Rockot(use gerrit already), 2016-07-07 23:44:52]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2016-07-07 23:45:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-08 03:47:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-08 03:48:00]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ken Rockot(use gerrit already), 2016-07-08 21:45:32]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-07-08 21:45:32]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org
Link to the patchset: https://codereview.chromium.org/2111353002/#ps260001
(title: "fix chrome shutdown on external service manager connection loss")

[commit-bot: I haz the power, 2016-07-08 21:46:09]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-08 21:59:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-08 21:59:11]

Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[Ken Rockot(use gerrit already), 2016-07-08 22:07:21]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-07-08 22:07:22]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org
Link to the patchset: https://codereview.chromium.org/2111353002/#ps280001
(title: "rebase")

[commit-bot: I haz the power, 2016-07-08 22:07:54]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2016-07-08 22:11:06]

Description was changed from

==========
Move content's shell connections to the IO thread

Moves all shell connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Cr-Commit-Position: refs/heads/master@{#404228}
==========

to

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Cr-Commit-Position: refs/heads/master@{#404228}
==========

[commit-bot: I haz the power, 2016-07-08 22:25:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-08 22:25:59]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[piman, 2016-07-08 22:42:17]

piman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2016-07-08 22:42:19]

https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:270: GetInterfaceRegistry()->PauseBinding();
drive-by, IIUC, this CL makes GpuConnectionFilter handle things on the IO
thread. How does this (which happens on the main thread) interact with
connection filters?

[Ken Rockot(use gerrit already), 2016-07-08 23:08:45]

On 2016/07/08 at 22:42:19, piman wrote:
>
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> File content/gpu/gpu_child_thread.cc (right):
> 
>
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> content/gpu/gpu_child_thread.cc:270: GetInterfaceRegistry()->PauseBinding();
> drive-by, IIUC, this CL makes GpuConnectionFilter handle things on the IO
thread. How does this (which happens on the main thread) interact with
connection filters?

There's no interaction between this and any ConnectionFilter. My understanding
from xhwang's comment (#12 on http://crbug.com/620845) is that
GpuProcessControlImpl and the media service they spawn from it don't depend on
full process initialization, so I used the ConnectionFilter to set it up here
without worrying about ordering. The relevant ARC interfaces are still
registered through this InterfaceRegistry and thus have their binding deferred
until OnInitialize.

Note that we intend to bootstrap the legacy IPC channel as just another
interface on the connection via a ConnectionFilter, so it doesn't make sense to
block all incoming connections outright. My assumption is that we can build a
helper to wrap interface binders here if/once it's really needed, but for now
using the main-thread InterfaceRegistry seems sufficient in such cases.

[piman, 2016-07-08 23:28:31]

On Fri, Jul 8, 2016 at 4:08 PM, <rockot@chromium.org> wrote:

> On 2016/07/08 at 22:42:19, piman wrote:
> >
>
>
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> > File content/gpu/gpu_child_thread.cc (right):
> >
> >
>
>
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> > content/gpu/gpu_child_thread.cc:270:
> GetInterfaceRegistry()->PauseBinding();
> > drive-by, IIUC, this CL makes GpuConnectionFilter handle things on the IO
> thread. How does this (which happens on the main thread) interact with
> connection filters?
>
> There's no interaction between this and any ConnectionFilter. My
> understanding
> from xhwang's comment (#12 on http://crbug.com/620845) is that
> GpuProcessControlImpl and the media service they spawn from it don't
> depend on
> full process initialization, so I used the ConnectionFilter to set it up
> here
> without worrying about ordering.
>

I worry that this may not true moving forward - from that comment "But as
piman@ said, we could run into similar issues in the future given we'll run
VDAv2 with GpuProcessControlImpl, which could have similar requirements as
ArcGpuVideoDecodeAccelerator"

In particular, knowing which VDA to create and how to configure it depends
on flags which aren't known until OnInitialize. For that matter, until
OnInitialize we don't even know if the GPU process will survive contact
with the enemy (buggy drivers....).


> The relevant ARC interfaces are still
> registered through this InterfaceRegistry and thus have their binding
> deferred
> until OnInitialize.
>
> Note that we intend to bootstrap the legacy IPC channel as just another
> interface on the connection via a ConnectionFilter, so it doesn't make
> sense to
> block all incoming connections outright. My assumption is that we can
> build a
> helper to wrap interface binders here if/once it's really needed, but for
> now
> using the main-thread InterfaceRegistry seems sufficient in such cases.
>

This is not about "legacy IPC" vs mojo, it's about "GPU process
initialization" vs mojo. It just happens that currently GPU process
initialization is driven by "legacy IPC". But the problem will still exist
if the GPU process initialization is driven by mojo. I think it *does* make
sense to block connections until the GPU process is fully initialized,
otherwise races galore.


I would really appreciate one of the content/gpu owners to review changes
to the GPU process initialization....


>
> https://codereview.chromium.org/2111353002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-07-08 23:59:08]

On 2016/07/08 at 23:28:31, piman wrote:
> On Fri, Jul 8, 2016 at 4:08 PM, <rockot@chromium.org> wrote:
> 
> > On 2016/07/08 at 22:42:19, piman wrote:
> > >
> >
> >
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> > > File content/gpu/gpu_child_thread.cc (right):
> > >
> > >
> >
> >
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> > > content/gpu/gpu_child_thread.cc:270:
> > GetInterfaceRegistry()->PauseBinding();
> > > drive-by, IIUC, this CL makes GpuConnectionFilter handle things on the IO
> > thread. How does this (which happens on the main thread) interact with
> > connection filters?
> >
> > There's no interaction between this and any ConnectionFilter. My
> > understanding
> > from xhwang's comment (#12 on http://crbug.com/620845) is that
> > GpuProcessControlImpl and the media service they spawn from it don't
> > depend on
> > full process initialization, so I used the ConnectionFilter to set it up
> > here
> > without worrying about ordering.
> >
> 
> I worry that this may not true moving forward - from that comment "But as
> piman@ said, we could run into similar issues in the future given we'll run
> VDAv2 with GpuProcessControlImpl, which could have similar requirements as
> ArcGpuVideoDecodeAccelerator"
> 
> In particular, knowing which VDA to create and how to configure it depends
> on flags which aren't known until OnInitialize. For that matter, until
> OnInitialize we don't even know if the GPU process will survive contact
> with the enemy (buggy drivers....).

OK, well I've reverted the change regarding ProcessControl binding. It is back
to
using the main-thread InterfaceRegistry for now.

> 
> 
> > The relevant ARC interfaces are still
> > registered through this InterfaceRegistry and thus have their binding
> > deferred
> > until OnInitialize.
> >
> > Note that we intend to bootstrap the legacy IPC channel as just another
> > interface on the connection via a ConnectionFilter, so it doesn't make
> > sense to
> > block all incoming connections outright. My assumption is that we can
> > build a
> > helper to wrap interface binders here if/once it's really needed, but for
> > now
> > using the main-thread InterfaceRegistry seems sufficient in such cases.
> >
> 
> This is not about "legacy IPC" vs mojo, it's about "GPU process
> initialization" vs mojo. It just happens that currently GPU process
> initialization is driven by "legacy IPC". But the problem will still exist
> if the GPU process initialization is driven by mojo. I think it *does* make
> sense to block connections until the GPU process is fully initialized,
> otherwise races galore.

My point was only that strictly blocking *all* interface binding is
fundamentally impossible, because at least one interface is required to drive
process initialization. In the near term that will be the "legacy IPC" Channel
interface, and eventually it will be something else. But it's still an interface
that needs to be bound before initialization is complete.

> 
> 
> I would really appreciate one of the content/gpu owners to review changes
> to the GPU process initialization....

Seems reasonable to me. So should content/gpu OWNERS set noparent?

> 
> 
> >
> > https://codereview.chromium.org/2111353002/
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to chromium-reviews+unsubscribe@chromium.org.
>

[piman, 2016-07-09 00:33:17]

LGTM, with one comment.

https://codereview.chromium.org/2111353002/diff/320001/content/browser/gpu/gp...
File content/browser/gpu/gpu_process_host.cc (right):

https://codereview.chromium.org/2111353002/diff/320001/content/browser/gpu/gp...
content/browser/gpu/gpu_process_host.cc:570:
BrowserThread::GetTaskRunnerForThread(BrowserThread::IO)));
FYI, this is already on the IO thread. This change means more posted tasks (that
may be unnecessary). Not sure if that's expected or not - it may be worth
special-casing.

[piman, 2016-07-09 00:33:22]

On Fri, Jul 8, 2016 at 4:59 PM, <rockot@chromium.org> wrote:

> On 2016/07/08 at 23:28:31, piman wrote:
>
> > On Fri, Jul 8, 2016 at 4:08 PM, <rockot@chromium.org&gt; wrote:
> >
> > > On 2016/07/08 at 22:42:19, piman wrote:
> > > >
> > >
> > >
>
>
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> > > > File content/gpu/gpu_child_thread.cc (right):
> > > >
> > > >
> > >
> > >
>
>
https://codereview.chromium.org/2111353002/diff/280001/content/gpu/gpu_child_...
> > > > content/gpu/gpu_child_thread.cc:270:
> > > GetInterfaceRegistry()->PauseBinding();
> > > > drive-by, IIUC, this CL makes GpuConnectionFilter handle things on
> the IO
> > > thread. How does this (which happens on the main thread) interact with
> > > connection filters?
> > >
> > > There's no interaction between this and any ConnectionFilter. My
> > > understanding
> > > from xhwang's comment (#12 on http://crbug.com/620845) is that
> > > GpuProcessControlImpl and the media service they spawn from it don't
> > > depend on
> > > full process initialization, so I used the ConnectionFilter to set it
> up
> > > here
> > > without worrying about ordering.
> > >
> >
> > I worry that this may not true moving forward - from that comment "But as
> > piman@ said, we could run into similar issues in the future given we'll
> run
> > VDAv2 with GpuProcessControlImpl, which could have similar requirements
> as
> > ArcGpuVideoDecodeAccelerator"
> >
> > In particular, knowing which VDA to create and how to configure it
> depends
> > on flags which aren't known until OnInitialize. For that matter, until
> > OnInitialize we don't even know if the GPU process will survive contact
> > with the enemy (buggy drivers....).
>
> OK, well I've reverted the change regarding ProcessControl binding. It is
> back
> to
> using the main-thread InterfaceRegistry for now.
>

Thanks.


> >
> >
> > > The relevant ARC interfaces are still
> > > registered through this InterfaceRegistry and thus have their binding
> > > deferred
> > > until OnInitialize.
> > >
> > > Note that we intend to bootstrap the legacy IPC channel as just another
> > > interface on the connection via a ConnectionFilter, so it doesn't make
> > > sense to
> > > block all incoming connections outright. My assumption is that we can
> > > build a
> > > helper to wrap interface binders here if/once it's really needed, but
> for
> > > now
> > > using the main-thread InterfaceRegistry seems sufficient in such cases.
> > >
> >
> > This is not about "legacy IPC" vs mojo, it's about "GPU process
> > initialization" vs mojo. It just happens that currently GPU process
> > initialization is driven by "legacy IPC". But the problem will still
> exist
> > if the GPU process initialization is driven by mojo. I think it *does*
> make
> > sense to block connections until the GPU process is fully initialized,
> > otherwise races galore.
>
> My point was only that strictly blocking *all* interface binding is
> fundamentally impossible, because at least one interface is required to
> drive
> process initialization. In the near term that will be the "legacy IPC"
> Channel
> interface, and eventually it will be something else. But it's still an
> interface
> that needs to be bound before initialization is complete.
>

Ok. Having a first connection to bootstrap things, deferring further
connections until initialization is complete makes sense.


> >
> >
> > I would really appreciate one of the content/gpu owners to review changes
> > to the GPU process initialization....
>
> Seems reasonable to me. So should content/gpu OWNERS set noparent?
>

That's probably unnecessary, and I think would cause unnecessary friction
for general changes...
More global reviewers usually defer to local OWNERs if they need reviewers
familiar with the code, for complex/subtle changes. I'm not sure if this
was deemed unnecessary here, or something was missed or what.


>
> >
> >
> > >
> > > https://codereview.chromium.org/2111353002/
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
> >
>
>
>
> https://codereview.chromium.org/2111353002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2016-07-09 00:48:31]

On 2016/07/09 at 00:33:17, piman wrote:
> LGTM, with one comment.
> 
>
https://codereview.chromium.org/2111353002/diff/320001/content/browser/gpu/gp...
> File content/browser/gpu/gpu_process_host.cc (right):
> 
>
https://codereview.chromium.org/2111353002/diff/320001/content/browser/gpu/gp...
> content/browser/gpu/gpu_process_host.cc:570:
BrowserThread::GetTaskRunnerForThread(BrowserThread::IO)));
> FYI, this is already on the IO thread. This change means more posted tasks
(that may be unnecessary). Not sure if that's expected or not - it may be worth
special-casing.

Yeah I considered special casing it (UtilityProcessHost has the same property),
but decided I'd rather treat that as an optimization and defer to a follow-up
CL.

[Ken Rockot(use gerrit already), 2016-07-09 01:01:10]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-07-09 01:01:11]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org
Link to the patchset: https://codereview.chromium.org/2111353002/#ps320001
(title: "revert some gpu changes")

[commit-bot: I haz the power, 2016-07-09 01:01:30]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-09 01:17:13]

Committed patchset #14 (id:320001)

[commit-bot: I haz the power, 2016-07-09 01:17:17]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-09 01:18:38]

Description was changed from

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Cr-Commit-Position: refs/heads/master@{#404228}
==========

to

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Committed: https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Cr-Original-Commit-Position: refs/heads/master@{#404228}
Cr-Commit-Position: refs/heads/master@{#404556}
==========

[commit-bot: I haz the power, 2016-07-09 01:18:40]

Patchset 14 (id:??) landed as
https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Cr-Commit-Position: refs/heads/master@{#404556}

[Ken Rockot(use gerrit already), 2016-07-11 22:58:47]

A revert of this CL (patchset #14 id:320001) has been created in
https://codereview.chromium.org/2138263002/ by rockot@chromium.org.

The reason for reverting is: http://crbug.com/627277.

[Ken Rockot(use gerrit already), 2016-07-14 22:42:02]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-14 22:42:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 01:43:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-15 01:43:10]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2016-07-15 02:53:40]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-15 02:53:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2016-07-15 02:54:25]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-15 02:54:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 05:30:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-15 05:30:40]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2016-07-15 20:33:10]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-15 20:33:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2016-07-15 21:19:23]

Description was changed from

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Committed: https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Cr-Original-Commit-Position: refs/heads/master@{#404228}
Cr-Commit-Position: refs/heads/master@{#404556}
==========

to

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500,619202

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Committed: https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Cr-Original-Commit-Position: refs/heads/master@{#404228}
Cr-Commit-Position: refs/heads/master@{#404556}
==========

[commit-bot: I haz the power, 2016-07-15 22:39:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-15 22:39:34]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2016-07-15 22:41:12]

It's unlikely that this CL could have actually caused the browser hangs seen on
some gpu test bots. As best as I can tell, it only made us more likely to
trigger an existing bug in cross-process pipe connection which could indeed lead
to such hangs.

That bug has been fixed so I'm going to reland this and keep a close eye on the
perf bots.

[Ken Rockot(use gerrit already), 2016-07-15 22:41:32]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-07-15 22:41:33]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org,
piman@chromium.org
Link to the patchset: https://codereview.chromium.org/2111353002/#ps380001
(title: "rebase")

[commit-bot: I haz the power, 2016-07-15 22:42:00]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 22:48:02]

Committed patchset #17 (id:380001)

[commit-bot: I haz the power, 2016-07-15 22:48:11]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-15 22:49:31]

Description was changed from

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500,619202

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Committed: https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Cr-Original-Commit-Position: refs/heads/master@{#404228}
Cr-Commit-Position: refs/heads/master@{#404556}
==========

to

==========
Move content's service manager connections to the IO thread

Moves all service manager connections in the content layer
(connections owned by instances of MojoShellConnection and
MojoChildConnection) to the IO thread in all process types.
Note that instances of MojoShellConnection and
MojoChildConnection may still be created and used on
any thread.

Additionally exposes a way for InterfaceRegistry and
InterfaceProvider to forward to/from other instances
so we can still have a corresponding instance of each
on whatever thread owns the Mojo[Shell/Child]Connection
object.

This simplifies interface registration and acquisition
on process hosts and ChildThreadImpls, and makes it possible
for a future CL to introduce IO-thread service registration
to avoid thread hops when binding incoming interface requests.

BUG=623398,612500,619202

Committed: https://crrev.com/439768f0aaaea83ffb7ce6c3ba4438804582c383
Committed: https://crrev.com/0771b1d71a3295691f9ffaefdf50652bd58e01c4
Committed: https://crrev.com/cef3827ff96c4fa12fcfbe95942f5d1b0a512a08
Cr-Original-Original-Commit-Position: refs/heads/master@{#404228}
Cr-Original-Commit-Position: refs/heads/master@{#404556}
Cr-Commit-Position: refs/heads/master@{#405885}
==========

[commit-bot: I haz the power, 2016-07-15 22:49:33]

Patchset 17 (id:??) landed as
https://crrev.com/cef3827ff96c4fa12fcfbe95942f5d1b0a512a08
Cr-Commit-Position: refs/heads/master@{#405885}