Each running program in its own box
Open a browser, a music player, and a code editor, and your operating system starts a separate process for each. Think of it as the program file brought to life: loaded into memory, given a unique process ID (PID), and scheduled to run on the CPU. Launch the same program twice and you get two processes, each unaware of the other's data.
The isolation is deliberate. The operating system gives each process its own memory space, so one cannot read or overwrite another's variables. If your editor crashes, the browser keeps going. Compare this to separate apartments in one building: each has its own lock and its own furniture, and residents must knock or phone to communicate.
Looking at processes from the shell
ps aux | grep node # list running processes that mention "node"
kill 4821 # ask process 4821 to stop
On Windows, Task Manager shows the same information. Every entry there is a process, and many programs, like Chrome, deliberately run several so that one misbehaving tab can't take the whole browser down.
Process vs thread
A thread is a line of execution inside a process. One process can contain many threads, all sharing its memory. Processes, by contrast, share nothing by default; to exchange data they need inter-process communication, such as pipes, sockets, files, or a shared database.
The trade-off comes down to safety versus cost. Processes are heavier to start and slower to talk between, but a bug in one stays contained. Threads are lighter and share data easily, at the price of needing care to avoid two threads corrupting the same value.
This is why Python programs often use the multiprocessing module for CPU-heavy jobs: separate processes each get their own interpreter and sidestep the GIL, which restricts threads in standard CPython.
Learn more
Last updated