with tasks in multiple categories including Input/VSync, Network, Script execution, DOM Events, Timer Callback, IdleCallback, GC/CC, etc. • Tasks of foreground tabs and background tabs in main thread are all executed in the same priority. • Goals • To categorize and prioritize these tasks in main thread to provide better responsiveness to the users. • Furthermore, tasks of the background tabs could be preempted if the preemption is not noticeable to the user. • This also provides an option to e10s-multi when fewer content processes are provided due to limited resources.
VSync Timer Callback GC Idle Callback Network Script DOM Event VSync High Normal Low Input VSync VSync DOM Event Timer Callback Network Script DOM Event GC Idle Callback Note: The order of tasks in the same priority are not changed
tabs are related by window.opener, window.parent • 2 tabs from different TabGroups are isolated, i.e., • A runnable in one tab can be run while a runnable in the tab of the other TabGroup is paused. • Only Async operation (postMessage) is allowed among the windows the same TabGroup. • DocGroup • A collection of documents from a given TabGroup that shares the same eTLD+1 of their origins. • Sync operations are allowed among the windows in the same DocGroup. • For example, A tab group with 4 windows of { x.a.com, y.a.com, x.b.com, y.b.com } will be arranged as: • TabGroup: • 2 DocGroups: { a.com, b.com }, each DocGroup collects 2 documents: • a.com: { x.a.com, y.a.com } • b.com: { x.b.com, y.b.com }
Network DOM Event Script Timer Callback Network Script DOM Event Network DOM Event Network Network DOM Event Script Script DOM Event Network DOM Event Timer Callback Scheduler The scheduler has to figure out which is the next task to be executed. Before After
all runnables dispatched to the main thread in content process. • Open bugs with high priority for labeling: https://wiki.mozilla.org/Quantum/DOM#Labeling • For sub-system experts, • Open a new bug dependent on labeling meta bug. • Review your implementation that uses any dispatching methods including • NS_DispatchTo(Main|Current)Thread • Dispatch() of nsIEventTarget and its inherited classes: • Where you holds the handle of the current/main thread for later dispatching. • AbstractThread::MainThread for MozPromise, Telemetry, etc. • nsITimerCallback(Func) which will be invoked on the owning thread of nsTimer. • subclass of nsExpirationTracker which applies a nsTimer for calling nsExpirationTrakcer::NotifyExpired(). • All ipc actor childs that are related to the contents. • The use of NS_New(In|Out)putStreamReadyEvent or the use of AsyncWait() on the (In| Out)putStream acquired from new Pipe() in js or NS_NewPipe() in native implementaiton. • The use of NS_New(In|Out)putStreamReadyEvent or the use of AsyncWait() on the (In| Out)putStream acquired from new Pipe() in js or NS_NewPipe() in native implementaiton. • The use of NS_ProxyRelease on main thread or NS_ReleaseOnMainThread • Replace with the new APIs introduced in upcoming slides.
nsIEventTarget* EventTargetFor(aTaskCategory) • AbstractThread* AbstractMainThreadFor(aTaskCategory) • Note: • Runnable inherits nsIRunnable and nsINamed, you can still have your runnable named for debugging for the use of last 2 APIs. • Naming convention: ClassName::MethodName or namespace::Runnable ClassName. • These APIs are accessible from nsIGlobalObject like nsDocument, nsGlobalWindow or from nsIDispacther like TabGroup, and DocGroup. • Access from TabGroup/DocGroup are corner cases and is not recommended. • TabGroup/DocGroup can be retrieved from nsPIDOMWindow::TabGroup() and nsPIDOMWindow::GetDocGroup()
child IPC request, i.e., SendXxxConstructor is done in child process: • IProtocol::SetEventTargetFor(aActor, aEventTarget) • For child actors created by parent IPC request, i.e., RecvXxxConstructor is done in child: • Normally, it inherits its event target from its manager. • If it’s not available, you must override GetConstructedEventTarget() of its top-level protocol like ContentChild, BackgroundChild, etc. • IProtocol::GetActorEventTarget(void) provides a handy way to retrieve the nsIEventTarget set by SetEventTargetFor()
your runnable inherits from WorkerRunnable, WorkerControlRunnable, WorkerMainThreadRunnable, the labeling has been covered internally in its ::Dispatch(). • If NS_DispatchToMainThread() is used, it can simply be replaced with • WorkerPrivate::DispatchToMainThread() • Because the WorkerPrivate holds an EventTargetFor(TaskCategory::Worker) for main- thread dispatching.
covered internally in AsyncEventDispatcher::PostDOMEvent() • Labeling for nsITimerCallback: • You can specify the EventTarget to run your callback by nsITimer::SetTarget(nsIEventTarget*)
label the runnable that doesn’t touch any content in child process: • SystemGroup::Dispatch(aName, aCategory, aRunnable) • SystemGroup::EventTargetFor(aCategory) • SystemGroup::AbstractMainThreadFor(aCategory) • What’s the impact of leaving a runnable unlabeled?
designed for Dispatching Runnables to the main thread in content process. • If your implementation runs in both main thread and non-main thread, NS_IsMainThread() helps you to check whether you have to dispatch from Dispatcher API or from NS_GetCurrentThread()/ NS_DispatchToCurrentThread().
bevistseng
teamlab
gionn
.png){kind=avatar}
codatum
willnet
4o1sobblue
camiha
jyouryuusui
pfn
yuuuuuuu168
genda
techtekt
prog893
rkendrick25
schlessera
uxyall
irinanazarova
elsirapls
wayneb77
maggiecrowley
soudai
reverentgeek
cassininazir
shpigford
tmiket
