All users were logged out of Bugzilla on October 13th, 2018

Stop using the chromium UI MessageLoop on the XPCOM thread

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
9 years ago
9 years ago

People

(Reporter: cjones, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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?
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.
That we call on the XPCOM thread?
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.
Is this still blocking bug 528146?

Comment 5

9 years ago
We are exclusively using the chromium UIMessageLoop now, since plugin processes at least don't have an XPCOM message loop at all.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.