On 3/30/2016 20:21, Kyle Huey wrote:
In the department-of-paying-down-technical-debt, I'm planning to remove
much of the Chromium event loop over the next few months. You can follow
along in bug 1260828.
The rough outline:
Step 1: Replace Task with nsIRunnable, without changing any other
semantics. This will happen in late April, after Gecko 48 branches.
Step 2: Either remove PostDelayedTask, or reimplement its semantics in
nsThread.
Step 3: Remove Chromium event loops using TYPE_DEFAULT and
TYPE_MOZILLA_NONMAINTHREAD. These are the simplest cases, because
TYPE_DEFAULT runs a Chromium Tasks only event loop, and
TYPE_MOZILLA_NONMAINTHREAD just glues delayed and idle tasks into the
normal XPCOM event loop.
Step 4: Tackle TYPE_MOZILLA_PARENT and TYPE_MOZILLA_CHILD. These run the
main threads of parent and content processes respectively, and aren't much
harder than step 3.
The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
involve varying levels of platform specific event loop or API integration
that will probably be more difficult to untangle. They also won't block my
long-term desire to build a scheduler for Gecko, so are lower priority.
If you have objections, speak now or forever hold your peace.
Few questions:
- how will this impact the IPC pumping that is based on Tasks?
- do you have more details/ideas/bugs about your scheduler? I may have
similar thoughts, like adding priorities to (not only) main thread
events. Backtrack (bug 1148204) should give hints (at least) how such a
scheduler should behave and check if does what we want.
-hb-
- Kyle
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
