How Chrome and Firefox use Processes & Threads
What are these processes and threads
Simply, a process can be thought of as a program in execution. A thread is the unit of execution within a process. A process can have anywhere from just one thread to many threads.
If you’re want to see the processes which are executed in your system, you can see it on your task manager in under the processing tab.But you can’t see threads that are running on the system. For get a little idea about threads, you can use the program known as “Process explorer”. You can download the program and it will show you threads that are running for an each program and each processes.
Let’s jump into processes and threads using by web browsers.
Processes and threads in Chrome
Practically you can see those processes in chrome through the task manager. There is a tab in task manager named as processes.From that you can get a rough idea about processes that are running in chrome.
However, If you ever look at the task manager while you working with chrome, you may have surprised that the number of chrome.exe entries are higher than number of actual chrome windows you had open. What do you think about the reason for that.
Google Chrome takes advantage of these properties and puts web apps and plug-ins in separate processes from the browser itself. This means that a rendering engine crash in one web app won’t affect the browser or other web apps. It means the OS can run web apps in parallel to increase their responsiveness, and it means the browser itself won’t lock up if a particular web app or plug-in stops responding. It also means we can run the rendering engine processes in a restrictive sandbox that helps limit the damage if an exploit does occur.
Basically, each tab has one process unless the tabs are from the same domain. The renderer has a process for itself. Each plug-in will have one and so will each extension that is active.
Every Chrome process has
- a main thread
- in the browser process (BrowserThread::UI): updates the UI
- in renderer processes (Blink main thread): runs most of Blink
- an IO thread
- in the browser process (BrowserThread::IO): handles IPCs and network requests
- in renderer processes: handles IPCs
- a few more special-purpose threads
- and a pool of general-purpose threads
Most threads have a loop that gets tasks from a queue and runs them (the queue may be shared between multiple threads).
Processes and threads in Firefox
In older versions of Firefox for desktop, the entire browser ran within a single operating system process. Specifically, the JavaScript that ran the browser UI (also known as “chrome code”) and the JavaScript that ran within web pages (also known as “content” or “web content”) were not separated.
Currently, the latest versions of Firefox run the browser UI and the web content in separate processes. In the current iteration of this architecture, all browser tabs run within the same process and the browser UI runs in its own individual process. In future iterations of Firefox, there will be more than one process to exclusively handle web content. The internal name for this project is called Electrolysis, sometimes abbreviated to e10s.
The good news is that normal web pages and their developers are unaffected by this changeover to a multiprocess-based Firefox. Unfortunately, people developing for Firefox or Firefox add-ons will be affected if their code relies on being able to access web content directly since the system for accessing this data is going to change.
Instead of accessing web content directly, chrome code will have to use the message manager instead. To help ease this transition we’ve implemented Cross Process Object Wrappers and some compatibility shims for add-on developers. If you are an add-on developer wondering whether or not you are affected by this change, see the guide to working with multiprocess Firefox.
NSPR provides an execution environment that promotes the use of lightweight threads. Each thread is an execution entity that is scheduled independently from other threads in the same process. This chapter describes the basic NSPR threading API.
- Threading Types and Constants
- Threading Functions
A thread has a limited number of resources that it truly owns. These resources include a stack and the CPU registers (including PC). To an NSPR client, a thread is represented by a pointer to an opaque structure of type PRThread. A thread is created by an explicit client request and remains a valid, independent execution entity until it returns from its root function or the process abnormally terminates. Threads are critical resources and therefore require some management. To synchronise the termination of a thread, you can join it with another thread . Joining a thread provides definitive proof that the target thread has terminated and has finished with both the resources to which the thread has access and the resources of the thread itself.
For an overview of the NSPR threading model and sample code that illustrates its use, see Introduction to NSPR.
For API reference information related to thread synchronisation, see Locks and Condition Variables.