Computer-Fundamentals/archive/os/processmanagement.md

Process Management for Software Engineering Interviews

Process management is the part of an operating system responsible for creating, scheduling, coordinating, and cleaning up running programs. In interview terms, it sits at the intersection of operating system theory and real production behavior: latency, throughput, fairness, isolation, resource sharing, and failure handling all depend on it.

If you already build backend systems, the practical framing is this:

• A process gives you isolation and a private virtual address space.
• A thread gives you a unit of execution inside a process.
• The scheduler decides who runs next.
• Context switches are the price the system pays to move the CPU from one runnable task to another.
• IPC exists because isolated execution units still need to cooperate.

This guide covers the theory, the Linux view, and the interview-level reasoning you should be able to explain clearly.

1. Processes and Threads

What is a process?

A process is a running instance of a program. It is more than just code on disk. Once started, the operating system gives it:

• Its own virtual address space
• A process identifier (PID)
• Open file descriptors
• Security credentials and environment variables
• Accounting information such as CPU time and memory usage
• One or more threads of execution

You can think of a process as a resource container plus execution context.

Typical process resources include:

• Code segment
• Heap
• Global data
• Open files and sockets
• Signal handlers
• Page tables and memory mappings

What is a thread?

A thread is the smallest schedulable unit of execution inside a process. Multiple threads in the same process share most process resources, but each thread still has its own:

• Program counter
• Register set
• Stack
• Thread-local storage

This is why threads are lighter than processes. Creating a new thread usually costs less than creating a new process, and switching between threads in the same process is usually cheaper than switching between unrelated processes.

Shared and private state inside a process

flowchart TB
	P["Process"]
	C["Shared: code / data / heap"]
	F["Shared: open files / sockets"]
	T1["Thread 1\nprivate stack\nprivate registers\nprivate PC"]
	T2["Thread 2\nprivate stack\nprivate registers\nprivate PC"]
	T3["Thread 3\nprivate stack\nprivate registers\nprivate PC"]

	P --> C
	P --> F
	P --> T1
	P --> T2
	P --> T3

Interview point: when two threads race on the same variable, that happens because they share the same address space. Two separate processes do not directly race on ordinary variables unless they use shared memory.

2. Process vs Thread

This comparison is foundational. Interviewers ask it directly because it reveals whether you understand isolation, scheduling, and communication costs.

Aspect	Process	Thread
Address space	Separate	Shared within the same process
Isolation	Stronger	Weaker
Failure impact	Crash is usually isolated to that process	A bad thread can crash the whole process
Creation cost	Higher	Lower
Context switch cost	Usually higher	Usually lower
Communication	IPC needed	Simple shared-memory access
Resource ownership	Own files, memory mappings, credentials	Uses process-owned resources
Security boundary	Commonly yes	Usually no

Practical interpretation

• Use processes when isolation matters more than sharing.
• Use threads when low-latency cooperation matters and shared memory is useful.
• Modern systems often mix both. For example, a service may run multiple worker processes, and each worker may use several threads.

Real-world examples

• PostgreSQL traditionally uses a process-per-connection model for strong isolation.
• MySQL commonly uses threads to handle many connections efficiently.
• Nginx uses a small number of worker processes, each running an event loop.
• The JVM runs as a process but internally uses many threads for application code, GC, JIT, and runtime services.

3. Process Lifecycle and Process States

Operating systems represent a process using metadata such as a Process Control Block (PCB). The PCB stores what the OS needs to manage and later resume the process.

Typical PCB content includes:

• PID and parent PID
• Current state
• CPU register snapshot
• Scheduling information such as priority
• Open file table references
• Memory management information
• Accounting and signal information

Core process states

The exact names vary across systems, but the standard model is:

• New: process is being created
• Ready: process is prepared to run but waiting for CPU time
• Running: process currently has the CPU
• Waiting or Blocked: process is waiting for I/O, a lock, a signal, or another event
• Terminated: process has finished execution

Some systems also expose suspended states when a process is swapped out or explicitly paused.

State transitions

stateDiagram-v2
	[*] --> New
	New --> Ready: admitted
	Ready --> Running: scheduler dispatch
	Running --> Ready: preempted / time slice ends
	Running --> Waiting: I/O wait / sleep / lock wait
	Waiting --> Ready: event completes
	Running --> Terminated: exit / kill
	Terminated --> [*]

How to explain the lifecycle in an interview

When a process is created, it starts in a creation phase, then enters the ready queue. The scheduler picks it to run. If it blocks on I/O, it moves to waiting. Once the I/O completes, it becomes ready again. Eventually it exits and becomes terminated. The scheduler and the kernel move processes among these states.

4. Process States and Context Switching

What is a context switch?

A context switch happens when the CPU stops executing one task and starts executing another. The operating system saves the execution context of the outgoing task and restores the saved context of the incoming task.

That saved context usually includes:

• Program counter
• Stack pointer
• General-purpose registers
• CPU flags
• Scheduling metadata
• Sometimes memory-management state such as page-table-related data

When do context switches happen?

Common triggers are:

• Timer interrupt fires and the running task is preempted
• Process blocks on I/O
• Process voluntarily yields
• Higher-priority task becomes runnable
• Kernel wakes a sleeping task

Context switch flow

sequenceDiagram
	participant CPU
	participant Scheduler
	participant A as Running Task A
	participant B as Next Task B

	CPU->>Scheduler: timer interrupt or blocking event
	Scheduler->>A: save registers, PC, stack pointer
	Scheduler->>Scheduler: choose next runnable task
	Scheduler->>B: restore saved context
	B->>CPU: resume execution

Mode switch vs context switch

These are related but not identical.

• A mode switch means the CPU moves between user mode and kernel mode.
• A context switch means the CPU changes which task is running.

For example, a system call may enter kernel mode and return to the same process without any context switch. Interviews often check whether you can separate these two ideas.

5. Context Switch Overhead and Performance Impact

Context switching is necessary, but it is not free.

Why it costs time

The kernel must:

• Save and restore CPU state
• Update scheduling structures
• Potentially switch address spaces
• Disturb CPU cache locality
• Potentially disturb TLB state

The direct overhead may be small, but the indirect overhead can be significant because the new task may need to warm caches again. That is why frequent switching can reduce throughput.

Process switch vs thread switch

Not all switches cost the same.

• Switching between threads in the same process often avoids some address-space work.
• Switching between unrelated processes usually has more memory-management overhead.
• User-space thread runtimes can switch very quickly between user threads, but if the underlying kernel thread blocks, the runtime can still stall.

Interview framing

If an interviewer asks why too-small time slices are bad, the answer is: they improve responsiveness up to a point, but after that the CPU spends too much time switching instead of doing useful work.

6. CPU Scheduling

Scheduling decides which ready task runs next. This is one of the most important process-management topics because it directly affects latency, throughput, fairness, and resource utilization.

Goals of CPU scheduling

Schedulers try to balance several goals that often conflict:

• High CPU utilization
• High throughput
• Low waiting time
• Low turnaround time
• Low response time
• Fairness
• Predictability

Definitions worth memorizing:

• Turnaround time: total time from submission to completion
• Waiting time: time spent waiting in the ready queue
• Response time: time until the task first gets CPU service

Ready queue mental model

The scheduler chooses from runnable tasks in the ready queue. When a task blocks, it leaves the ready queue. When I/O completes, it re-enters.

7. Scheduling Algorithms

You should know how each algorithm works, where it performs well, and what tradeoffs it makes.

First-Come, First-Served (FCFS)

FCFS runs the task that arrived earliest.

How it works:

• Non-preemptive
• Tasks run in arrival order
• Once a task gets CPU, it keeps it until it blocks or finishes

Strengths:

• Very simple
• Low scheduling overhead
• Easy to reason about

Weaknesses:

• Poor response time for short interactive tasks
• Convoy effect: a long CPU-bound job can force many short jobs to wait behind it

Interview note: FCFS is fair in arrival order, but not fair in terms of responsiveness.

Shortest Job First (SJF)

SJF picks the job with the smallest CPU burst.

How it works:

• Classic SJF is non-preemptive
• If exact burst lengths were known, it minimizes average waiting time

Strengths:

• Excellent theoretical average waiting time

Weaknesses:

• Real systems rarely know the future burst length exactly
• Long jobs can starve if short jobs keep arriving

Shortest Remaining Time First (SRTF)

SRTF is the preemptive version of SJF.

How it works:

• If a newly arrived task has a shorter remaining burst than the currently running one, the scheduler preempts

Strengths:

• Better response for short jobs than non-preemptive SJF

Weaknesses:

• More context-switch overhead
• Still depends on burst estimation

Round Robin (RR)

Round Robin gives each runnable task a time slice, often called a quantum.

How it works:

• Preemptive
• Each task gets CPU for at most one quantum
• If it does not finish, it goes to the back of the ready queue

Strengths:

• Good response time for interactive systems
• Prevents one task from monopolizing the CPU

Weaknesses:

• Too small a quantum increases context-switch overhead
• Too large a quantum makes it behave more like FCFS

Interview note: the key tuning parameter is the time quantum. That parameter determines the tradeoff between responsiveness and overhead.

Priority Scheduling

Priority scheduling picks the highest-priority runnable task.

How it works:

• Can be preemptive or non-preemptive
• Priorities may be static or dynamic

Strengths:

• Lets critical or latency-sensitive work run sooner
• Useful in systems with service classes or real-time priorities

Weaknesses:

• Starvation risk for low-priority tasks

Common fix:

• Aging gradually increases the priority of waiting tasks so they eventually run

Scheduling algorithm comparison

Algorithm	Preemptive	Main strength	Main weakness	Good fit
FCFS	No	Simplicity	Convoy effect	Very simple batch workloads
SJF	No	Great average waiting time in theory	Needs burst prediction	Controlled batch-style systems
SRTF	Yes	Excellent for short jobs	Higher overhead, starvation risk	Short-job-heavy workloads
Round Robin	Yes	Good responsiveness	Quantum tuning matters	Time-sharing and interactive systems
Priority	Either	Favors important tasks	Starvation risk	Systems with service differentiation

What modern Linux does

Linux does not use plain FCFS or Round Robin for normal tasks. Its Completely Fair Scheduler (CFS) tries to approximate fairness by tracking virtual runtime. The task that has received the least fair share of CPU tends to run next.

High-level intuition:

• CPU-hungry tasks accumulate runtime quickly
• Tasks that sleep often, such as interactive or I/O-heavy ones, do not accumulate runtime while sleeping
• When they wake up, they often get CPU relatively quickly

This is one reason interactive systems feel responsive even under load.

8. Preemptive vs Non-Preemptive Scheduling

Non-preemptive scheduling

Once a task gets the CPU, it keeps it until it finishes, blocks, or voluntarily yields.

Pros:

• Simpler implementation
• Lower context-switch overhead

Cons:

• Poor responsiveness
• A long-running job can delay everyone else

Preemptive scheduling

The OS can interrupt a running task and give the CPU to another runnable task.

Pros:

• Better responsiveness
• Better support for fairness and latency-sensitive work

Cons:

• More scheduler complexity
• More context-switch overhead
• More concurrency hazards inside kernels and runtimes

Interview summary

Preemption improves responsiveness and fairness, especially in multi-user and interactive systems. Non-preemptive scheduling is simpler and sometimes easier to reason about, but it performs poorly when short tasks sit behind long ones.

9. CPU-Bound vs I/O-Bound Processes

This distinction explains a lot about scheduler behavior.

CPU-bound process

A CPU-bound process spends most of its time doing computation. It has long CPU bursts and relatively little waiting for I/O.

Examples:

• Compression
• Video encoding
• Large numerical workloads
• Data transformation jobs

I/O-bound process

An I/O-bound process spends much of its time waiting on disk, network, or other external events. It has short CPU bursts and frequent waits.

Examples:

• Web servers waiting on sockets
• Database clients waiting for query results
• Log processors waiting on disk or network streams

Why the distinction matters

• CPU-bound tasks benefit from throughput-oriented scheduling and cache locality.
• I/O-bound tasks benefit from quick wakeup and good response time.
• A good general-purpose scheduler tries not to let CPU-bound work starve interactive or I/O-heavy tasks.

Backend-system intuition

Many backend services are mostly I/O-bound at the request level. They parse a request, hit storage or another service, wait, and resume. That is why event-driven systems and efficient wakeup behavior matter so much in real server software.

10. Inter-Process Communication (IPC)

Processes are isolated by design, so the OS provides explicit communication mechanisms.

IPC is used for:

• Data exchange
• Coordination
• Event notification
• Work distribution
• Accessing services across process boundaries

Two broad IPC models

• Shared memory: processes map a common memory region and communicate by reading and writing the same bytes
• Message passing: the OS or runtime moves discrete messages between processes

IPC decision view

flowchart TD
	A["Need communication between execution units"] --> B{"Same address space?"}
	B -->|Yes| C["Threads: shared memory by default\nneed synchronization"]
	B -->|No| D{"Same machine?"}
	D -->|Yes| E["Pipes / FIFOs / shared memory / message queues / Unix sockets"]
	D -->|No| F["Network sockets / RPC / messaging systems"]

11. Shared Memory vs Message Passing

Shared memory

With shared memory, two or more processes map the same physical memory pages into their virtual address spaces.

Strengths:

• Very fast for large data exchange
• Avoids repeated kernel copying after setup

Weaknesses:

• Harder to program correctly
• Requires synchronization to avoid races and corruption
• Debugging becomes more difficult

Common use cases:

• High-performance analytics pipelines
• Multimedia systems
• Shared in-memory caches on the same host

Message passing

With message passing, processes send discrete messages through kernel-managed mechanisms or runtime-managed queues.

Strengths:

• Cleaner isolation
• Easier reasoning about ownership
• Usually simpler failure boundaries

Weaknesses:

• More copying and syscall overhead in many cases
• Message size and serialization can matter

Common use cases:

• Microservices
• Worker queues
• Actor-style systems
• Parent-child control channels

Comparison

Topic	Shared Memory	Message Passing
Performance	Often faster for large local data	Often simpler but can add copy/serialization overhead
Synchronization	Required explicitly	Often built into the communication model
Isolation	Weaker	Stronger
Complexity	Higher	Lower to moderate
Typical scope	Same machine	Same machine or across network

Interview framing: shared memory is usually about performance; message passing is usually about simplicity, isolation, and explicit communication.

12. Pipes, Named Pipes, Sockets, and Message Queues

Pipes

A pipe is a unidirectional byte stream, commonly used between related processes such as parent and child processes.

Key properties:

• Kernel-managed buffer
• Often used with fork()
• Traditional Unix shell pipelines use anonymous pipes

Example:

• ps aux | grep python connects the output of one process to the input of another through a pipe

Named Pipes (FIFOs)

A named pipe is like a pipe with a filesystem name.

Key properties:

• Unrelated processes can open it by name
• Still typically local to one machine
• Useful for simple producer-consumer communication

Sockets

Sockets are a general communication endpoint.

Types you should know:

• Unix domain sockets: efficient IPC on the same machine
• TCP sockets: reliable communication across a network
• UDP sockets: connectionless communication with lower overhead and weaker delivery guarantees

Why sockets matter in interviews:

• They connect OS process management to real backend systems
• Most network services ultimately communicate through sockets

Message Queues

Message queues store discrete messages, often with ordering and notification semantics.

Key properties:

• Decouple sender and receiver
• Can support asynchronous communication
• OS-level queues exist, and distributed systems also use message brokers such as Kafka or RabbitMQ at a higher layer

Interview note: OS message queues and distributed message brokers are conceptually related but not the same thing.

13. Signals and Semaphores

These are often mentioned together, but they solve different problems.

Signals

A signal is an asynchronous notification sent to a process or thread.

Common Linux signals:

• SIGTERM: polite request to terminate
• SIGKILL: immediate kill, cannot be caught or ignored
• SIGINT: interrupt from terminal, commonly Ctrl+C
• SIGCHLD: child process changed state

Important properties:

• Signals are not a good mechanism for transferring large data
• Signal handlers run asynchronously, so only async-signal-safe operations are safe there
• They are often used for control, shutdown, reload, or notification

Real-world example:

• Nginx can receive signals to reload configuration or stop workers gracefully

Semaphores

A semaphore is a synchronization primitive used to control access to shared resources.

Two types:

• Binary semaphore: value is effectively 0 or 1, similar in spirit to a lock
• Counting semaphore: value can be greater than 1, useful when a finite number of identical resources exist

Use cases:

• Limit concurrency to N workers
• Coordinate producer-consumer pipelines
• Protect access to shared data structures

Important clarification:

• A semaphore is mainly about synchronization and coordination
• A signal is mainly about asynchronous notification

14. Parent and Child Processes

Processes often form hierarchies.

Parent-child relationship

When one process creates another, the creator is the parent and the new process is the child.

In Unix-like systems, a child inherits many attributes from the parent, such as:

• Environment
• Open file descriptors
• Current working directory
• Credentials and limits

Linux model: fork() and exec()

The classic Unix pattern is:

1. Parent calls fork()
2. Kernel creates a child process
3. Child often calls exec() to replace its memory image with a new program
4. Parent may call wait() or waitpid() to collect the child's exit status

This separation is a major OS design idea:

• fork() duplicates the current process state
• exec() replaces that state with a new program image

Copy-on-write optimization

Modern Unix systems do not eagerly copy every memory page during fork(). They use copy-on-write.

That means:

• Parent and child initially share the same physical pages as read-only
• Only when one side writes to a page does the kernel create a private copy

This makes fork() practical even for large processes.

Parent-child lifecycle diagram

flowchart LR
	P["Parent process"] --> F["fork()"]
	F --> C["Child process"]
	C --> E["exec() optional\nreplace program image"]
	C --> X["exit(status)"]
	P --> W["wait()/waitpid()"]
	X --> W

15. Process Creation and Termination

Process creation

When a process is created, the OS typically:

• Allocates a PCB or equivalent task structure
• Assigns a PID
• Sets up memory mappings or address-space references
• Initializes registers and stack for the first instruction
• Places the new task in the ready queue

Process termination

A process may terminate because:

• It returns from main
• It calls exit()
• It receives a fatal signal
• The OS or an administrator kills it
• It crashes due to an exception

Termination involves:

• Releasing memory and kernel resources
• Closing or decrementing references to open resources
• Recording the exit status for the parent
• Notifying the parent if needed

16. Zombie and Orphan Processes

These are classic interview questions.

Zombie process

A zombie is a process that has finished execution, but whose parent has not yet collected its exit status with wait() or waitpid().

Important detail:

• The zombie is not really running anymore
• Most resources are already released
• A small process-table entry remains so the parent can read the exit status

Why zombies matter:

• If a parent never reaps children, zombie entries accumulate and consume process-table slots

Orphan process

An orphan is a child whose parent exits before the child does.

What happens next:

• The orphan is adopted by a system reaper process, historically init, and on many Linux systems effectively managed under systemd
• The new parent eventually reaps it when it exits

Interview distinction

• Zombie: child is dead, parent is still alive, exit status not yet collected
• Orphan: child is alive, parent is dead

This distinction is asked constantly, so answer it precisely.

17. Multithreading Basics

Multithreading means using multiple threads of execution within a process.

Why use multithreading?

• Improve throughput on multi-core CPUs
• Overlap waiting with useful work
• Keep applications responsive
• Separate responsibilities such as request handling, background work, and monitoring

Benefits

• Lower creation and communication cost than processes
• Shared memory makes cooperation fast
• Fits server workloads with many concurrent activities

Risks

• Race conditions
• Deadlocks
• False sharing and cache contention
• Harder debugging and reproducibility

Backend examples

• A Java web server may use a thread pool to process requests
• A database engine may use dedicated background threads for flushing, compaction, or replication
• A runtime may use one thread for networking and others for CPU-heavy work

18. User Threads vs Kernel Threads

This topic is important because it connects thread abstraction to actual scheduling.

Kernel threads

Kernel threads are visible to the operating system scheduler.

Properties:

• The kernel can schedule them directly on CPUs
• If one blocks in the kernel, other kernel threads of the process can still run
• They usually have higher creation and switch overhead than pure user threads

User threads

User threads are managed by a user-space runtime or library.

Properties:

• Very fast to create and switch in many designs
• Scheduler logic can be customized in user space
• A blocking system call can stall progress if the model maps many user threads onto one kernel thread

Common mapping models

• 1:1: each user thread maps to one kernel thread
• N:1: many user threads map to one kernel thread
• M:N: many user threads multiplex over several kernel threads

Tradeoffs

Model	Strength	Weakness
Kernel threads	True parallelism and better blocking behavior	More kernel overhead
User threads	Fast user-space scheduling	Blocking and multicore limitations in simple models

Real-world view

• Most mainstream runtimes on Linux today rely heavily on kernel threads
• Some runtimes add lightweight user-space scheduling on top, such as goroutines in Go
• Go still uses kernel threads underneath, but the runtime multiplexes many goroutines onto them

19. Linux and Modern Backend Systems

Linux process model

Linux internally represents processes and threads using closely related task structures. From the kernel's point of view, threads are largely tasks that share selected resources such as memory mappings and file tables.

That is why low-level Linux APIs such as clone() are central to thread creation. Different sharing flags determine what is shared.

Common production patterns

Pre-fork servers

Some servers create a pool of worker processes up front.

Why this is useful:

• Fault isolation between workers
• Predictable memory layout
• Simple concurrency model

Examples:

• Older Apache models
• Gunicorn worker processes

Thread pools

Many application servers maintain a fixed or elastic pool of threads.

Why this is useful:

• Avoids thread creation cost per request
• Limits concurrency to something the system can handle
• Provides backpressure when the pool is saturated

Examples:

• Java servlet containers
• C++ RPC servers

Event-driven systems

Some high-concurrency systems avoid one-thread-per-request and instead use event loops.

Why this is useful:

• Handles many I/O-bound connections efficiently
• Reduces context-switch and stack overhead

Examples:

• Nginx
• Node.js plus libuv
• Redis single-threaded command execution with I/O multiplexing

Practical interview insight

When choosing between processes, threads, and event loops, the answer is usually not theoretical purity. It is about workload shape:

• Need strong isolation: lean toward processes
• Need easy shared state and moderate concurrency: lean toward threads
• Need huge numbers of mostly idle connections: lean toward event-driven models

20. Common Interview Questions and Practical Scenarios

1. What is the difference between a process and a thread?

Strong answer:

A process is an isolated resource container with its own virtual address space. A thread is a schedulable execution path inside a process. Threads share process memory and resources, which makes them cheaper to create and communicate through, but also makes them less isolated.

2. Why is context switching expensive?

Strong answer:

Because the system must save and restore execution state, run scheduling logic, and often lose cache and TLB locality. The indirect cache effects are often more expensive than the raw register save and restore.

3. Why can Round Robin improve responsiveness?

Strong answer:

Because every runnable task gets CPU time within a bounded interval, rather than waiting for a long task to finish. That makes interactive workloads feel responsive, assuming the quantum is chosen well.

4. What is the convoy effect?

Strong answer:

In FCFS, a long CPU-bound task at the front of the queue can force many short or I/O-heavy tasks to wait behind it, reducing system responsiveness and utilization.

5. What is the difference between a zombie and an orphan?

Strong answer:

A zombie has already exited but still has an unreaped process-table entry. An orphan is still running but has lost its parent; it gets adopted by the system reaper.

6. When would you use processes instead of threads?

Strong answer:

When fault isolation, security boundaries, or independent resource limits matter more than cheap shared-memory communication. Multi-tenant services, worker isolation, and plugin sandboxes are common examples.

7. When would you use shared memory instead of message passing?

Strong answer:

When processes on the same machine need very high-throughput, low-copy data exchange and you can handle the synchronization complexity. Otherwise, message passing is often simpler and safer.

8. Why are I/O-bound tasks often favored in practice?

Strong answer:

Because short bursts and quick wakeups improve latency for interactive users and servers. A scheduler that only optimizes raw throughput can make the system feel slow even if utilization looks good.

9. What happens during fork() and exec()?

Strong answer:

fork() creates a child based on the parent, usually using copy-on-write for memory efficiency. exec() then replaces the current process image with a new program while typically keeping the same PID.

10. Why do backend systems often use thread pools?

Strong answer:

They amortize thread creation cost, bound concurrency, and provide a place to enforce resource control and backpressure.

21. Practical Scenarios Interviewers Like

Scenario: API server under high latency to downstream services

What matters:

• Requests become I/O-bound
• One-thread-per-request can work, but large concurrency may increase memory and scheduling overhead
• Event-driven or async designs may scale better for waiting-heavy workloads

Good interview discussion:

Talk about how waiting dominates CPU bursts, why schedulers can keep the CPU busy with other work, and why thread pools or async I/O can reduce overhead.

Scenario: CPU-heavy image processing service

What matters:

• Work is CPU-bound
• Number of active workers should roughly track available cores
• Excessive threading may hurt due to context switching and cache contention

Good interview discussion:

Explain that for CPU-bound workloads, more concurrency than available cores often hurts throughput. Bounded worker pools and process isolation may both be sensible, depending on memory and fault-tolerance needs.

Scenario: Parent spawns workers but never waits for them

What matters:

• Exited workers become zombies
• Process-table entries accumulate
• Fix is to reap children, often with waitpid() or a SIGCHLD handling strategy

Scenario: Two services on the same machine need low-latency communication

What matters:

• Unix domain sockets are often a strong default
• Shared memory may be faster for large payloads but requires careful synchronization
• Pipes are simple but less flexible for general bidirectional service communication

22. Common Mistakes in Interviews

• Saying a process is just a program on disk. A process is a running program plus OS-managed execution state and resources.
• Saying threads are independent like processes. They are not; they share address space and many resources.
• Confusing mode switches with context switches.
• Forgetting that SJF is mainly theoretical unless you can estimate burst lengths.
• Forgetting starvation as a tradeoff in SJF and priority scheduling.
• Saying zombies are running processes. They are not running; they are already dead.
• Treating semaphores and signals as interchangeable. They solve different problems.

23. How to Build Strong Interview Answers

When answering process-management questions, aim for this structure:

1. Define the concept precisely
2. Explain the tradeoff
3. Give a systems example
4. Mention one practical failure mode or performance implication

For example, for threads vs processes:

• Definition: processes isolate memory, threads share it
• Tradeoff: processes give isolation, threads give cheaper communication
• Example: PostgreSQL uses processes; many app servers use thread pools
• Failure mode: memory corruption in one thread can crash the whole process

That answer shape is usually stronger than a short textbook definition.

24. Final Mental Model

If you remember only one picture, remember this:

• Processes are about isolation and resource ownership
• Threads are about execution inside that resource container
• Scheduling is about deciding who gets CPU time
• Context switching is the cost of moving among runnable tasks
• IPC is how isolated tasks cooperate
• Real systems choose among processes, threads, and event loops based on workload shape, not ideology

That mental model is enough to connect interview theory to actual Linux behavior and backend system design.