Processes and Threads: The Groundwork Before the Browser Series

You already know one conclusion: a browser is multi-process, and each tab has (roughly) its own process. But now that you've understood that sentence, more basic questions probably surface:

• What exactly is a process?
• What is a thread?
• What's the real difference between the two?

If this set of concepts isn't clear, then "the browser is multi-process" is just a memorized conclusion — you don't actually understand why it's designed that way. So this article lays the first slab of foundation for the browser series: explaining processes and threads (and how they relate to memory) in the most down-to-earth way. Read it first, then go back to that article — it'll feel much smoother.

• Tell apart two easily confused concepts: "program" and "process"
• Use analogies to understand what a "process" and a "thread" each are
• Grasp the core difference between processes and threads: who owns resources and who shares them
• Understand how they relate to memory: why processes are isolated from each other while threads share
• Build the groundwork for "why the browser is multi-process"

• No programming background needed, and no C or operating systems knowledge required
• You can read the first article of the browser series first and come back with questions, or read this one first

On your computer, the browser, a chat app, a music player, and maybe an editor are open at the same time. Look closer:

• In the browser, one tab is playing a video, another is downloading a file in the background, and you're scrolling in a third — three things happening at once.
• Yet the browser never worries that "playing the video will scramble the download's data," nor does one tab breaking blow up the whole application.

Some very basic concepts are hiding here. Open your computer's Activity Monitor (macOS) or Task Manager (Windows) and you'll see a long list: the browser, the chat app, and the music player each take a row; expand the browser and a pile of sub-entries unfold underneath.

Those line-by-line things — some are called processes, and some relate to threads. Let's take them one at a time.

Many people treat "program" and "process" as the same thing, but they're not.

• Program: a static file sitting on your disk. Like WeChat.exe or Google Chrome.app. By itself it does nothing — it's like a recipe.
• Process: an instance of the program after it starts running — the whole act of "cooking from the recipe."

Here's an easy-to-remember analogy:

So:

• Double-clicking a browser icon starts a process.
• The same program can run several processes at once — open three terminal windows and there are actually three terminal processes running.

A process is the basic unit for the operating system to allocate resources, and also the basic unit of isolation. Remember this sentence; we'll unpack it below.

When the operating system starts a process, it allocates a set of resources that belong to that process, and the most important one is — its own chunk of memory.

You can picture a process as an independent workshop:

• The workshop has its own floor, tools, and materials (corresponding to the process's memory and system resources).
• Different workshops are walled off from each other: a worker in workshop A can't see or touch anything in workshop B.

This "walling off" matters enormously, and it brings two benefits:

• Stability: if one process crashes, it doesn't drag down another.
• Security: a program in one process can't casually peek at another process's data.

A workshop alone isn't enough — someone has to do the work. That's a thread.

• A thread is the unit that actually executes code inside a process — think of it as a worker in the workshop.
• A process can have one or more threads, letting several things progress at once.
• A thread cannot exist without a process — a worker needs a workshop to work in.

When a process starts, it carries at least one thread, usually called the main thread.

If you remember only one sentence, remember this: a process is the "owner of resources," a thread is the "unit of execution."

Expanded into a table:

The most important row in that table is Memory.

• Processes' memory is walled off, so isolation is strong — but exchanging data is a hassle.
• Threads share the same chunk of memory, so exchanging data is extremely fast — but that also means almost no isolation: if one thread corrupts memory, the whole process (all its threads) suffers together.

We've kept mentioning "memory," so let's make the relationship clear:

• Every process has its own independent memory space. This is the root of isolation — precisely because memory isn't shared, process A can't touch process B.
• A thread has no independent memory of its own. It uses the memory of the process it belongs to, and only additionally owns a small stack, used to record "where I'm currently executing and what my local variables are."

Therefore:

That's also why:

• To make two things completely independent, put them in different processes;
• To do several things at once while sharing data quickly, use multiple threads in the same process.

The deeper details (virtual memory, address spaces, page tables) get involved, so we won't unpack them here. For now, just build the intuition that "process memory is independent, threads share the process's memory."

Now, rereading "the browser is multi-process" clicks:

• The browser puts different pages (more precisely, different sites) into different processes, precisely to exploit process isolation: a page crashing, freezing, or even carrying malicious code can't reach the others.
• And inside each page process, the browser uses multiple threads (the main thread running JS, the compositor thread handling image composition, and so on) to push rendering and computation forward in parallel.

Put together, this is the underlying logic of the browser's architecture:

1. See what a process is

   Open Activity Monitor (macOS) or Task Manager (Windows). Find the browser, the chat app, and the music player — each is one (or a group of) process. Watch their CPU and memory usage.

2. One program, many processes

   Open three terminal windows (or three text editors). Search in Activity Monitor and you'll find they correspond to multiple processes. This confirms that "one program can have several processes at once."

3. Processes inside the browser

   In Chrome/Edge, press Shift + Esc to open the browser's own task manager. You'll see each tab and each extension taking its own row — roughly one process each (the more precise "site isolation" rule comes in the next article).

• Why does "one of two tabs crashing not affect the other," while "many tasks running at once inside one page is fine"? Hint: the former relies on process isolation, the latter on thread concurrency. Explain each using the concepts from this article.

• A program is static (a file on disk); a process is a running instance.
• A process is the basic unit of resource allocation and isolation; a thread is an execution unit inside a process, and every process has at least one (main) thread.
• The core difference: a process owns independent memory (strong isolation, costly communication); a thread shares the process's memory (fast communication, weak isolation).
• Mnemonic: processes handle isolation, threads handle concurrency.
• These concepts are exactly the groundwork for understanding "why the browser is multi-process."

Keywords: program, process, thread, main thread, address space, isolation, concurrency

The groundwork is laid. The next stop is the browser itself: why it splits pages into different processes, and which threads live inside one page.

And if you later want to understand "why one chunk of JS freezes the main thread," continue with: