On Sat, Apr 8, 2017 at 6:03 AM, Chris Peterson <cpeter...@mozilla.com> wrote:
> > Are the bugs to label runnables good for volunteer contributors? Or would > it be fastest for a DOM expert or engineers from each module to rip through > the open bugs? Do we need to ask module owners to prioritize these bugs? :) > > https://bugzilla.mozilla.org/showdependencytree.cgi?id=13218 > 12&hide_resolved=1 > > It will be faster for the engineers from each module to check these bugs that are unassigned yet. The reason will be explained later. The latest analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1333984#c11 gives us some hint to prioritize these bugs even though some runnables are still anonymous. According to a searchfox search for unlabeled runnable calls (using the > function names billm provided), there are still over 800 unlabeled > runnables: > > http://searchfox.org/mozilla-central/search?q=%5CbNS_Dispatc > hTo(Main%7CCurrent)Thread+*%5C(&case=true®exp=true&path= > <http://searchfox.org/mozilla-central/search?q=%5CbNS_DispatchTo%28Main%7CCurrent%29Thread+*%5C%28&case=true®exp=true&path=> > > This is only the first glance for labeling runnables but not all of them has to be labeled. The reasons why we need engineers instead of volunteers to check first are that 1. All runnables needed to be labeled are the runnables dispatched to the *main thread of the content process*. 2. 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 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 if its actor child is created on the main thread.) - Subclass of *nsExpirationTracker * (Bugs of 1347823 <https://bugzilla.mozilla.org/show_bug.cgi?id=1347823>, 1350676 <https://bugzilla.mozilla.org/show_bug.cgi?id=1350676>, 1350677 <https://bugzilla.mozilla.org/show_bug.cgi?id=1350677>, 1350678 <https://bugzilla.mozilla.org/show_bug.cgi?id=1350678>, 1350828 <https://bugzilla.mozilla.org/show_bug.cgi?id=1350828>, 1351639 <https://bugzilla.mozilla.org/show_bug.cgi?id=1351639>, 1351869 <https://bugzilla.mozilla.org/show_bug.cgi?id=1351869> are created for tracking this) - 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 runnables named "(In|Out)putStreamReadyEvent" to the specified nsIEventTarget which needs to be labeled if the nsIEventTarget points to the main thread.) Hence, we can expect that the scope in some of these labeling bugs are big. Once engineers of each module break down them into more specific tasks, we can get help from volunteer easier. There are several meta bugs as good examples for breaking down these labeling tasks per module: Bug 1339343 <https://bugzilla.mozilla.org/show_bug.cgi?id=1339343> (Layout-labeling) Bug 1339676 <https://bugzilla.mozilla.org/show_bug.cgi?id=1339676> (Netwerk-labeling) Bug 1341537 <https://bugzilla.mozilla.org/show_bug.cgi?id=1341537> (gfx-labeling) Bug 1341539 <https://bugzilla.mozilla.org/show_bug.cgi?id=1341539> (labeling in dom/media) _______________________________________________ > 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
