OS Vocabulary: Process, Thread, Kernel, Syscall

Isolation comes from the process boundary; cheap concurrency comes from threads. Four OS terms behind why two processes can't share backpressure.

Isolation comes from the process boundary; cheap concurrency comes from threads (and goroutines).

Four Words, One Diagram

Process = a running program with its own private memory and files. Process A dying leaves Process B unaffected. That’s why the screenshot service and browser sidecar have independent OOM fates (Shared Resource Blast Radius).
Thread = one line of execution inside a process, sharing the same memory. Cheap concurrency starts here; goroutines are even cheaper (~2KB vs ~1MB) (GMP Scheduler and Netpoller).
Kernel vs user-space: the kernel has full hardware access; your program runs in a user-space sandbox and can only ask the kernel to act via a syscall.
Syscall (read, epoll_wait…) = the only legal door through the wall. Not free; each one requires a mode switch, which is why epoll exists: check thousands of sockets in one call (GMP Scheduler and Netpoller).

Role in This OOM

The screenshot service (Go app) and browser are two separate processes, each with its own memory and its own OOM. Go’s GOMEMLIMIT can govern its own heap but cannot reach another process’s memory (Wrong Fix: GOMEMLIMIT and Git Archeology).

There’s no automatic backpressure between two processes. When one is about to blow, the other doesn’t stop on its own.

References:

Related: see Runtime Environment for where your code actually runs, GMP Scheduler and Netpoller for how goroutines wait on I/O, or go back to the series overview.

Tags #go #concurrency #reliability