[ozone-dev] Ozone with on the IO thread

['Chris Mumford' via Ozone-Dev]

Hoping for some help from the Ozone dev's...

So I've got a test that uses the RenderViewHostTestHarness
<https://cs.chromium.org/chromium/src/content/public/test/test_renderer_host.h?type=cs&q=RenderViewHostTestHarness&l=190>,
but it sets the TestBrowserThreadBundle::IO_MAINLOOP option because it
reads/writes values that can only be accessed on the IO thread. At present
this works on all platforms except those using Ozone. It's failing this one
check:

FATAL:message_loop.h(440)] Check failed: loop->IsType(MessageLoop::TYPE_UI).

It looks like all platforms *except Ozone* can create a window on the IO
thread. (see WindowTreeHostPlatform()
<https://cs.chromium.org/chromium/src/ui/aura/window_tree_host_platform.cc?type=cs&q=WindowTreeHostPlatform::WindowTreeHostPlatform&l=42>),
but it's the X11WindowOzone that calls AddPlatformEventDispatcher that
results in this exception.

Any clever ideas as to the best way to solve this?

[Michael Spang]

I am surprised if this works on other platforms. I would not expect it to
work, especially on platforms that actually have a different message pump
on the UI thread (e.g. MessagePumpForUI in message_pump_win).

On ozone, UI and IO message pumps are exactly the same class
(MessagePumpLibevent). I am not aware of anything fundamental that prevents
this from working, only the thread affinity assertions done using the
message loop type. Of course the reason we are using a UI message loop on
the UI thread is just to satisfy similar assertions going the other way.

I am not sure if what you are asking is really supported; you may find it
easiest to just create separate threads since your test needs to do two
things that are affine to different well-named threads and have assertions
to verify this.

Michael

On Wed, Feb 21, 2018 at 1:34 PM 'Chris Mumford' via Ozone-Dev <

Post by 'Chris Mumford' via Ozone-Dev
Hoping for some help from the Ozone dev's...
So I've got a test that uses the RenderViewHostTestHarness
<https://cs.chromium.org/chromium/src/content/public/test/test_renderer_host.h?type=cs&q=RenderViewHostTestHarness&l=190>,
but it sets the TestBrowserThreadBundle::IO_MAINLOOP option because it
reads/writes values that can only be accessed on the IO thread. At present
this works on all platforms except those using Ozone. It's failing this one
loop->IsType(MessageLoop::TYPE_UI).
It looks like all platforms *except Ozone* can create a window on the IO
thread. (see WindowTreeHostPlatform()
<https://cs.chromium.org/chromium/src/ui/aura/window_tree_host_platform.cc?type=cs&q=WindowTreeHostPlatform::WindowTreeHostPlatform&l=42>),
but it's the X11WindowOzone that calls AddPlatformEventDispatcher that
results in this exception.
Any clever ideas as to the best way to solve this?

['Michael Spang' via Ozone-Dev]

If it really is true that MessageLoopIO is expected to work for
PlatformWindow, then it should work for us to just change the UI thread to
an IO message loop for ozone. As I mentioned, it's the same class; you'd
just replace all of the instances of MessageLoopForUI with MessageLoopForIO.

Post by Michael Spang
I am surprised if this works on other platforms. I would not expect it to
work, especially on platforms that actually have a different message pump
on the UI thread (e.g. MessagePumpForUI in message_pump_win).
On ozone, UI and IO message pumps are exactly the same class
(MessagePumpLibevent). I am not aware of anything fundamental that prevents
this from working, only the thread affinity assertions done using the
message loop type. Of course the reason we are using a UI message loop on
the UI thread is just to satisfy similar assertions going the other way.
I am not sure if what you are asking is really supported; you may find it
easiest to just create separate threads since your test needs to do two
things that are affine to different well-named threads and have assertions
to verify this.
Michael
On Wed, Feb 21, 2018 at 1:34 PM 'Chris Mumford' via Ozone-Dev <

Post by 'Chris Mumford' via Ozone-Dev
Hoping for some help from the Ozone dev's...
So I've got a test that uses the RenderViewHostTestHarness
<https://cs.chromium.org/chromium/src/content/public/test/test_renderer_host.h?type=cs&q=RenderViewHostTestHarness&l=190>,
but it sets the TestBrowserThreadBundle::IO_MAINLOOP option because it
reads/writes values that can only be accessed on the IO thread. At present
this works on all platforms except those using Ozone. It's failing this one
loop->IsType(MessageLoop::TYPE_UI).
It looks like all platforms *except Ozone* can create a window on the IO
thread. (see WindowTreeHostPlatform()
<https://cs.chromium.org/chromium/src/ui/aura/window_tree_host_platform.cc?type=cs&q=WindowTreeHostPlatform::WindowTreeHostPlatform&l=42>),
but it's the X11WindowOzone that calls AddPlatformEventDispatcher that
results in this exception.
Any clever ideas as to the best way to solve this?

[Robert Kroeger]

On Wed, Feb 21, 2018 at 2:57 PM, 'Michael Spang' via Ozone-Dev <

Post by 'Michael Spang' via Ozone-Dev
If it really is true that MessageLoopIO is expected to work for
PlatformWindow, then it should work for us to just change the UI thread to
an IO message loop for ozone. As I mentioned, it's the same class; you'd
just replace all of the instances of MessageLoopForUI with MessageLoopForIO.

Post by Michael Spang
I am surprised if this works on other platforms. I would not expect it to
work, especially on platforms that actually have a different message pump
on the UI thread (e.g. MessagePumpForUI in message_pump_win).

In particular, I'd expect it to fail on Mac and Win.

Post by 'Michael Spang' via Ozone-Dev

Post by Michael Spang
On ozone, UI and IO message pumps are exactly the same class
(MessagePumpLibevent). I am not aware of anything fundamental that prevents
this from working, only the thread affinity assertions done using the
message loop type. Of course the reason we are using a UI message loop on
the UI thread is just to satisfy similar assertions going the other way.
I am not sure if what you are asking is really supported; you may find it
easiest to just create separate threads since your test needs to do two
things that are affine to different well-named threads and have assertions
to verify this.
Michael
On Wed, Feb 21, 2018 at 1:34 PM 'Chris Mumford' via Ozone-Dev <

Post by 'Chris Mumford' via Ozone-Dev
Hoping for some help from the Ozone dev's...
So I've got a test that uses the RenderViewHostTestHarness
<https://cs.chromium.org/chromium/src/content/public/test/test_renderer_host.h?type=cs&q=RenderViewHostTestHarness&l=190>,
but it sets the TestBrowserThreadBundle::IO_MAINLOOP option because it
reads/writes values that can only be accessed on the IO thread. At present
this works on all platforms except those using Ozone. It's failing this one
TYPE_UI).
It looks like all platforms *except Ozone* can create a window on the
IO thread. (see WindowTreeHostPlatform()
<https://cs.chromium.org/chromium/src/ui/aura/window_tree_host_platform.cc?type=cs&q=WindowTreeHostPlatform::WindowTreeHostPlatform&l=42>),
but it's the X11WindowOzone that calls AddPlatformEventDispatcher that
results in this exception.
Any clever ideas as to the best way to solve this?

Not really. It's really much better to setup Ozone on the UI thread.