Operating Systems

01What an OS actually is

Strip away everything and an OS is a resource multiplexer with an armed guard:

      USER MODE                      KERNEL MODE
┌───────────────────┐          ┌─────────────────────┐
│ your FastAPI app  │  syscall │  kernel             │
│ psycopg2          │ ───────► │  scheduler          │
│ node service      │ ◄─────── │  virtual memory     │
│ kafka client      │  return  │  filesystem, TCP/IP │
└───────────────────┘          └─────────────────────┘

Everything below is a consequence of these two jobs.

02Processes vs threads

The process: an isolation unit

A process is a running program plus everything the kernel tracks about it: its own virtual address space, file descriptor table, PID, credentials, signal handlers. The keyword is isolation — process A literally cannot address process B's memory (the page tables don't map it).

The thread: an execution unit

A thread is a schedulable stream of execution inside a process. Threads in the same process share the address space (heap, globals, code), file descriptors, and signal dispositions. Each thread privately owns its stack (local variables, call frames) and its register state / program counter.

03Context switching

The CPU runs one thread per core at a time. To switch, the kernel:

1. Interrupt fires (timer tick, or thread blocks on I/O, or syscall returns).
2. Kernel saves the current thread's registers + program counter into its task struct.
3. Scheduler picks the next runnable thread.
4. Kernel restores that thread's registers; if it's a different process, it also swaps the page table pointer (CR3 on x86) — which invalidates chunks of the TLB (the cache of virtual→physical translations).
5. Return to user mode; the new thread continues as if nothing happened.

Cost: the register save/restore is ~1–2 µs, but the real tax is cold caches — the new thread's data isn't in L1/L2, and TLB misses pile up. Effective cost can be tens of microseconds.

04Scheduling basics

• The kernel keeps runnable threads in run queues (per-CPU). Linux's default is CFS/EEVDF ("completely fair"): every thread accumulates vruntime (weighted runtime); the scheduler always runs the thread that has had the least. Nice values weight it.
• Preemptive: a timer interrupt guarantees no thread can hog a core — the kernel forcibly context-switches. (Contrast: an asyncio event loop is cooperative — a coroutine that never awaits blocks everyone. Same concept, opposite policy.)
• I/O-bound vs CPU-bound: I/O-bound threads run briefly then block (on read, recv…), so they get scheduled quickly when data arrives — good latency. CPU-bound threads eat full time slices. Your API services are overwhelmingly I/O-bound: they spend their lives waiting on Postgres, Redis, OpenSearch, and LLM APIs.

05Memory: stack, heap, virtual memory, paging

Stack vs heap

High addresses
┌──────────────┐
│    stack     │  ← grows down. Call frames, locals. Auto-freed on return.
│      ↓       │
│   (unused)   │
│      ↑       │
│    heap      │  ← grows up. malloc / Python objects. Freed by GC/free().
├──────────────┤
│  globals/BSS │
├──────────────┤
│  code (text) │
└──────────────┘
Low addresses

• Stack: allocation is "bump a pointer" — basically free. Lifetime = the function call. Fixed max size (default ~8 MB on Linux) → deep recursion = stack overflow (Python guards with RecursionError at ~1000 frames before the real stack would blow).
• Heap: for data whose lifetime outlives a function call or whose size is dynamic. In Python, every object lives on the heap — the stack just holds references. Allocation is managed by the allocator (pymalloc for Python, V8's heap for Node) and reclaimed by GC.

Virtual memory & paging

Every process sees a private, flat address space starting near 0. That's a lie the MMU maintains:

• Memory is managed in pages (4 KB typically). A page table (per process) maps virtual pages → physical frames. The TLB caches these translations.
• A virtual page can be: mapped to RAM, mapped to a file (mmap — how executables and shared libs load), swapped to disk, or not mapped at all (→ segfault on access).
• Page fault = you touched a page with no valid mapping. It's not always an error: the kernel uses faults to lazily allocate memory (allocate-on-first-touch) and to load mmap'd file pages on demand. A "major fault" means disk I/O was needed — slow.
• Copy-on-write (CoW): fork() doesn't copy memory; parent and child share pages marked read-only, and copies happen per-page on first write. This is why forking a fat process is cheap — and why gunicorn's --preload shares your app's memory across workers.

06File descriptors

To the kernel, everything you can read/write is a file descriptor: files, pipes, sockets (every HTTP connection!), timers, even event-notification handles (epoll). An FD is just a small integer indexing into the process's FD table.

• 0 = stdin, 1 = stdout, 2 = stderr. This is why container logging works: your app writes to stdout, the runtime captures FD 1, kubectl logs reads the capture.
• Every Postgres connection in your pool, every Kafka broker connection, every accepted HTTP request = 1 socket = 1 FD.
• FDs are limited (ulimit -n, often 1024 by default, raised in prod). "Too many open files" during a traffic spike or a connection leak is an FD exhaustion bug — a classic war story to have ready.
• epoll (Linux) is the mechanism that lets one thread monitor thousands of FDs: "tell me which of these sockets are readable." This is the syscall your asyncio/uvloop event loop and Node's libuv are built on. The event loop is epoll with a nice API.

07Syscalls

A syscall is a controlled function call into the kernel: put the syscall number + args in registers, execute a trap instruction (syscall on x86-64), CPU switches to kernel mode, kernel does the work, returns.

Ones you invoke constantly without thinking: read/write, open, socket/connect/accept/send/recv, epoll_wait, futex (what locks use to sleep), mmap, fork/execve, clone (creates threads and processes on Linux — a thread is just a clone() that shares the address space).

Syscalls cost ~hundreds of nanoseconds (mode switch + work). That's why high-performance I/O batches them (writev, sendfile, io_uring) and why "chatty" code (one tiny write per log line, per-byte parsing on sockets) gets slow.

08Signals

Signals are the kernel's asynchronous nudge mechanism — a software interrupt delivered to a process.

K8s pod termination — know this cold:

kubectl delete pod / rollout
       │
       ▼
1. Pod marked Terminating; removed from Service endpoints
2. SIGTERM sent to PID 1 in each container   ← your graceful-shutdown hook
3. terminationGracePeriodSeconds (default 30s) countdown
4. Still alive? SIGKILL. No appeal.

09Containers = namespaces + cgroups

There is no "container" in the kernel. A container is not a VM. It's a normal Linux process wearing blinders and a straitjacket:

VM:         App → Guest OS kernel → Hypervisor → Host kernel → HW
Container:  App ──────────────────────────────► Host kernel → HW
                 (same kernel! just namespaced + cgrouped)

Consequences you've lived:

• Containers share the host kernel — that's why they start in milliseconds and why uname -r in any pod shows the node's kernel.
• A K8s pod = a group of containers sharing the same network (and IPC) namespace — which is exactly why sidecars talk to your app over localhost.
• kubectl exec = spawn a process inside the container's namespaces (nsenter conceptually).
• Resource limits/requests are literally cgroup settings written by the kubelet.

10Python's GIL

The Global Interpreter Lock is a mutex inside CPython: only one thread may execute Python bytecode at a time, per process. It exists because CPython's memory management (refcounts on every object) isn't thread-safe without it.

What it does and doesn't mean:

• CPU-bound Python + threads = no parallelism. Two threads crunching numbers take as long as one (worse — GIL handoff overhead). Fix: multiprocessing / process pools (each process has its own GIL), or push work into C (NumPy releases the GIL) — or Python 3.13+ free-threaded builds (experimental).
• I/O-bound Python + threads = fine. The GIL is released during blocking I/O (socket reads, file I/O, time.sleep, most C-extension work). While one thread waits on Postgres, another runs. So a threaded scraper or a run_in_executor call genuinely overlaps work.
• Async doesn't "beat" the GIL — it sidesteps the question. One thread, so the GIL is uncontended; concurrency comes from the event loop interleaving I/O waits.

Q&AInterview questions you should be able to answer

✓Self-test — explain it out loud before opening