I’m often asked to explain the threading model of the DOM. From the perspective of JavaScript (today), execution is essentially single threaded. But beneath the hood things are a bit more complicated. Some of this discussion is applicable across browsers, but a fair bit is Gecko specific. I made a picture but can’t seem to embed it usefully in my blog :P

The first thread of interest is the “main thread”. This is the thread that JS embedded in documents runs on. In Gecko, it’s also the thread that does most of the layout work, processes native UI events from the operating system, does bookkeeping for a lot of the networking code, and much more. Tying up this thread for long periods of time starves these other tasks and makes the browser “jank”, or not respond promptly to input. And compounding this problem, JS uses a “run to completion” scheduling mechanism where execution is not preempted to do other work.

For web pages that want to do long running background processing without yielding we created Web Workers, an abstraction for threads that communicate solely through asynchronous message passing. Workers have access to some APIs such as XMLHttpRequest and IndexedDB but not others, such as Nodes or DOMParser. This allows limited forms of background processing but little UI interaction (although that is changing a bit!).

The main thread and worker threads are the only threads within the browser that run JS. But there are many more threads involved in the implementation of the DOM and related APIs.

---

All of our network I/O (opening, closing, and polling sockets) has long happened on a pool of network threads. For similar reasons, database and storage operations such as those for localStorage or IndexedDB also happen on a pool of background threads. The UI (main) thread needs to remain responsive no matter how slow your network connection or disk is! We’ve also sought to move long running tasks with little interaction with the rest of the browser off the main thread. The HTML parser usually runs on its own thread. And for some types of loads (such as normal page loads), the networking threads talk directly to the parser thread, while for other types (such as XHR or Fetch) the networking threads talk to the main thread.

There’s also a single IPC thread dedicated to passing IPDL messages between threads and processes via pipes. This thread connects both the main thread and worker threads to PBackground-based protocols, and connects the main thread to PContent-based protocols. The simplified picture linked at the beginning of this article diagrams how all these threads link together.

There are also some other threads that I didn’t include in the diagram. Inside the JS engine Spidermonkey also does threaded script parsing and garbage collection. And HTML media elements connect to machinery for audio and video playback that involves off-main-thread decoding and rendering pipelines. These are generally outside the scope of the “DOM team” at Mozilla, because those subsystems are maintained by other teams (the JS team and the Media Playback team respectively) and have little effect on most of the DOM.

While the threading model visible to JS is pretty simple, inside Gecko there’s a lot more complexity. This is why we do things like document which thread code is expected to run on, assert that objects are refcounted on the correct thread even in opt builds, and generally structure threaded code to use message passing and event loops (via nsIRunnable) rather than using complex systems of shared memory and locks. Relatively modern threaded code, such as our Web Worker or IndexedDB implementations demonstrate many of these best practices. And of course, I and other experienced engineers are always happy to answer questions.

http://blog.kylehuey.com/post/141859564272