528147 - Stop using the chromium UI MessageLoop on the XPCOM thread

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

AFAICT, this was done because we had originally expected to use the chromium IPC code as-is, and that code posts IPC messages to be processed back to the "UI" thread.  But IPDL uses its own message processors, AsyncChannel et al., and these can easily be modified to post back to the XPCOM event loop.

bent, can you think of any other reasons we use the UI MessageLoop?

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

There are about a gabillion places in chromium code that do things like |MessageLoop::current()->foo()| which will cease to function if we try. As long as we're using chromium at all I think we're stuck.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

That we call on the XPCOM thread?

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Oh ... there's PostTask(), when we need to tell the IO thread to do something.  That takes a Location parameter that ends up touching thread storage.  But this should be easy to disable or fake.

Comment 4

[Benoit Girard (:BenWa)]

Is this still blocking bug 528146?

Comment 5

[Benjamin Smedberg]

We are exclusively using the chromium UIMessageLoop now, since plugin processes at least don't have an XPCOM message loop at all.