Quantum/DOM: Difference between revisions

Jump to navigation Jump to search
1,327 bytes added ,  10 April 2017
Add "Q3: What runnables shall be labeled?" in FAQ
(Tweak Concepts)
(Add "Q3: What runnables shall be labeled?" in FAQ)
Line 266: Line 266:
<b>A:</b> For people who want to participate in these labeling tasks, there is a list of good labeling bugs is linked off [https://bugzilla.mozilla.org/show_bug.cgi?id=labeling bug 1321812]. We will use telemetry to decide which runnables are most important, and updates will be posted to that bug. (Note: the analysis of the telemetry is available in [https://bugzilla.mozilla.org/show_bug.cgi?id=1333984 bug 1333984].)
<b>A:</b> For people who want to participate in these labeling tasks, there is a list of good labeling bugs is linked off [https://bugzilla.mozilla.org/show_bug.cgi?id=labeling bug 1321812]. We will use telemetry to decide which runnables are most important, and updates will be posted to that bug. (Note: the analysis of the telemetry is available in [https://bugzilla.mozilla.org/show_bug.cgi?id=1333984 bug 1333984].)


For sub-system experts, besides clearing the list above related to your sub-system, we need your help to look for calls to NS_DispatchTo{Main,Current}Thread or nsIThread::Dispatch, and the use cases of TimerCallback and IPC actor childs in your sub-system to file more bugs to ensure that all runnables to be labeled are covered and will be fixed. In general, no matter how frequent the runnable appears in the analysis list, '''all main-thread runnables in the content process need to be lableled''' to prevent the impact explained in Q1 because the happened rate will be the accumulation of the happened rates of all these unlabeled runnables. Otherwise, the benefit we get from Quantum-DOM will be significantly reduced.
For sub-system experts, besides clearing the list above related to your sub-system, we need your help to look for the use cases mentioned in '''Q3'''. In general, no matter how frequent the runnable appears in the analysis list, '''all main-thread runnables in the content process need to be lableled''' to prevent the impact explained in Q1 because the happened rate will be the accumulation of the happened rates of all these unlabeled runnables. Otherwise, the benefit we get from Quantum-DOM will be significantly reduced.


=== Q3: How do I specify a label for an nsITimer TimerCallback? ===
=== Q3: What runnables shall be labeled? ===
<b>A:</b> All the runnables ​dispatched to '''the main thread of the content process''' shall be labeled.
 
In addition to '''NS_Dispatch(Main|Current)Thread''', there are several ways to trigger a runnable to the main thread implicitly:
 
* Any calls to the '''Dispatch()''' method of the subclass of '''nsIEventTarget'''.
* The use of AbstractThread::MainThread() (Most of them shall be covered in [https://bugzilla.mozilla.org/show_bug.cgi?id=1314833 bug 1314833])
* The use of '''nsITimer'''. (The timer callback will be called by a runnable to the current thread according to nsTimer implementaiton).
* Handled the received messages in '''IPC actor childs'''. (A received message will be handled on main thread with a new runnable if its actor child is created on the main thread.)
* Subclass of '''nsExpirationTracker''' (The overriden method of NotifyExpired() will be triggered implicitly with a new runnable by the internal timer in nsExpirationTracker implementation. See the dependency tree of [https://bugzilla.mozilla.org/show_bug.cgi?id=1345464 bug 1345464] for the list of the sub-classes.)
* 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'''. (These 2 use cases trigger new runnables '''named (In|Out)putStreamReadyEvent''' to the specified nsIEventTarget which needs to be labeled if the nsIEventTarget points to the main thread.)
 
=== Q4: How do I specify a label for an nsITimer TimerCallback? ===


<b>A:</b> This can be done by <code>nsITimer::SetTarget(nsIEventTarget*)</code> combined with <code>EventTargetFor</code>. See the XMLHttpRequest example above.
<b>A:</b> This can be done by <code>nsITimer::SetTarget(nsIEventTarget*)</code> combined with <code>EventTargetFor</code>. See the XMLHttpRequest example above.


=== Q4: Will the <code>TaskCategory</code> be used for prioritizing in the future? ===
=== Q5: Will the <code>TaskCategory</code> be used for prioritizing in the future? ===


If it will, how can developers ensure that the ordering won't be a problem if tasks are labeled in different categories in current developing stage?
If it will, how can developers ensure that the ordering won't be a problem if tasks are labeled in different categories in current developing stage?
Line 278: Line 290:
<b>A:</b> It may be used for scheduling in the future. Generally, anything that's not marked as Other should come from some outside source (usually IPC, but also from a timer). In that case, we have a lot of freedom about when to schedule it. So there shouldn't be too many concerns about breaking things as long as people follow that rule.
<b>A:</b> It may be used for scheduling in the future. Generally, anything that's not marked as Other should come from some outside source (usually IPC, but also from a timer). In that case, we have a lot of freedom about when to schedule it. So there shouldn't be too many concerns about breaking things as long as people follow that rule.


=== Q5: Do runnables need to be labeled in the main process? ===
=== Q6: Do runnables need to be labeled in the main process? ===


<b>A:</b> No. Only content process runnables need to be labeled. But labeling other runnables won't break anything.
<b>A:</b> No. Only content process runnables need to be labeled. But labeling other runnables won't break anything.
Confirmed users
205

edits

Navigation menu