Lesson 2: Processes & Kernel Interface

After this lesson, you can write fork() + exec() + wait() from memory, trace every file descriptor through a pipeline, and explain the full path of Ctrl+C from keystroke to SIGINT delivery. You can read Ghostty's src/termio/Exec.zig and understand every line.

What is an Operating System? #

The OS is a referee. Three jobs:

1. Isolation: process A cannot read process B's memory (unless explicitly shared). The kernel enforces this with page tables and privilege rings.
2. Multiplexing: 300 processes on 8 cores. The kernel switches between them (context switch: save registers, load new process's registers, switch page tables).
3. Abstraction: files, sockets, pipes and processes are all abstractions. The hardware has disk blocks, network packets, and memory. The kernel gives you a coherent interface.

What is a Process? #

A process is a task_struct (Linux): a kernel data structure containing:

The kernel maintains exactly one task_struct per process. When a process is not running, its register state is saved in its task_struct. A context switch loads the next process's register state from its task_struct.

Process lifecycle #

fork() #

pid_t pid = fork();
if (pid == 0) {
    // child: pid is 0
} else {
    // parent: pid is the child's PID
}

fork() clones the calling process. Both parent and child continue executing from the same point (the instruction after fork()). They are identical except:

• fork() returns child PID to parent, 0 to child
• Child gets a new PID
• File descriptors are shared (both point to the same kernel file table entries)
• Pending signals are not inherited

Why fork() is fast #

Copy-on-write. The kernel copies the page table, not the pages. Both parent and child's page table entries point to the same physical pages, marked read-only. When either writes, the hardware triggers a page fault. The kernel allocates a new physical page, copies the data, updates the page table, marks it writable, and resumes. Only pages that actually diverge get copied.

exec() #

execl("/bin/ls", "ls", "-l", NULL);   // list form, null-terminated
execvp("ls", argv);                    // p = search PATH
execve("/bin/ls", argv, envp);        // ve = vector + environment

exec() replaces the current process image with a new program. It does NOT create a new process. The PID, file descriptors (unless marked CLOEXEC), and process group remain unchanged. What changes: the address space (new page tables), the program counter (entry point of the new binary), the stack, and the registers.

The ELF loader mmaps segments lazily:

• .text (code): read-only, executable, demand-paged from the binary file
• .data (initialized globals): read-write, copy-on-write from the binary
• .bss (zero-initialized globals): anonymous read-write pages, zero-filled on first access
• Stack and heap: anonymous pages

File Descriptors #

File descriptors are integers that index into a per-process table. Three kernel tables are involved:

Three levels:

1. Per-process fd table: fd → pointer to open file entry. Defaults: 0=stdin, 1=stdout, 2=stderr.
2. Open file table (kernel-global): tracks the current file offset and access mode. Multiple fd entries (across processes!) can point to the same open file entry.
3. Vnode table: the actual file/inode. Multiple open file entries can point to the same vnode.

pipe() #

int fds[2];
pipe(fds);  // fds[0] = read end, fds[1] = write end

A pipe is a kernel buffer with a read end and write end. Writes append to the buffer. Reads consume from it. When the buffer is full, write() blocks. When the buffer is empty and the write end is closed, read() returns 0 (EOF).

dup2() #

dup2(fds[1], STDOUT_FILENO);  // close(1), then copy fds[1] → fd 1

dup2(oldfd, newfd) makes newfd point to the same open file entry as oldfd. If newfd was open, it's closed first. This is how redirection works.

Why open() returns 3 #

open() returns the lowest available file descriptor. 0, 1, and 2 are already taken (stdin, stdout, stderr). So open() returns 3.

Building a Pipeline (ls | wc) #

int pipefd[2];
pipe(pipefd);  // create pipe BEFORE forking

if (fork() == 0) {
    // Child 1: ls
    close(pipefd[0]);                    // close read end
    dup2(pipefd[1], STDOUT_FILENO);      // redirect stdout → pipe
    close(pipefd[1]);                    // close original write fd
    execlp("ls", "ls", NULL);
}

if (fork() == 0) {
    // Child 2: wc
    close(pipefd[1]);                    // close write end
    dup2(pipefd[0], STDIN_FILENO);       // redirect stdin → pipe
    close(pipefd[0]);                    // close original read fd
    execlp("wc", "wc", NULL);
}

// Parent: close BOTH ends
close(pipefd[0]);
close(pipefd[1]);
wait(NULL); wait(NULL);

wait() and Zombies #

A process that has exited but not yet been waited on is a zombie. The kernel keeps the task_struct and exit status so the parent can collect it. A zombie consumes a PID and a small amount of kernel memory.

pid_t pid = wait(&status);       // blocks until any child exits
pid_t pid = waitpid(pid, &status, WNOHANG);  // non-blocking, specific child

When the parent calls wait(), the zombie is reaped: the kernel frees the task_struct. If the parent exits first, children are reparented to PID 1 (init), which reaps them.

SIGCHLD #

Instead of blocking on wait(), the parent can register a SIGCHLD handler:

void sigchld_handler(int sig) {
    int saved_errno = errno;
    while (waitpid(-1, NULL, WNOHANG) > 0) {}  // reap all zombies
    errno = saved_errno;
}
signal(SIGCHLD, sigchld_handler);

The while loop is necessary because multiple children may have exited before the handler runs (signals are not queued: multiple SIGCHLDs can be coalesced into one delivery).

Signals #

Signals are asynchronous notifications from the kernel to a process. Lifecycle:

pending (kernel sets a bit) → delivered (handler runs or default action)

A signal can be blocked (delivery deferred) via the signal mask. While blocked, the signal remains pending. Standard signals (< 32) are not queued: multiple deliveries of the same signal may be coalesced.

Key signals for terminals #

How Ctrl+C works end-to-end #

1. User presses Ctrl+C on keyboard
2. Ghostty receives the key event, writes 0x03 (ASCII ETX) to the PTY master
3. The line discipline receives 0x03, checks ISIG flag in termios (enabled by default)
4. Line discipline sends SIGINT to the foreground process group of the terminal
5. Each process in the foreground group receives SIGINT
6. Default action: terminate

minish Project #

The incremental shell project spans this lesson. Each version adds one capability.

v1: Basic REPL (~30 lines) #

while (1) {
    printf("$ ");
    fgets(line, sizeof(line), stdin);
    if (fork() == 0) {
        execvp(argv[0], argv);
        perror("exec");
        exit(1);
    }
    wait(NULL);
}

Purpose: feel the fork/exec/wait cycle in your fingers.

v2: PATH resolution #

Parse $PATH (colon-separated directories). For each command, try <dir>/<command> with access(X_OK). Use the first match.

v3: Pipes #

Parse |. Create one pipe per |. Fork N+1 children for N pipes. Wire stdin/stdout with dup2. Close all pipe ends in the parent.

v4: Redirection #

Parse <, >, >>. open() with O_CREAT|O_TRUNC|O_APPEND. dup2 into stdin/stdout.

v5: Background jobs + signals #

Parse &. Don't wait for background processes. Install SIGCHLD handler that reaps zombies with waitpid(WNOHANG). Block SIGCHLD during critical sections.

v6: Job control #

Track jobs (pid, command, state: running/stopped). Implement fg and bg builtins. Use tcsetpgrp() to give terminal control to the foreground process. Handle SIGTSTP (Ctrl+Z) to suspend, SIGCONT to resume.

v7: PTY integration (see Lesson 3) #

Replace pipes with a PTY pair. openpty() → fork → child dup2(slave, 0/1/2) → exec(zsh). Parent reads/writes master fd. Now minish has the same I/O architecture as Ghostty (minus the GUI).

Ghostty Source to Study #

Self-Check #

Can you:

• Write fork() + exec() + wait() from memory
• Draw the three kernel tables (fd, open file, vnode) and trace dup2()
• Explain why a zombie exists and how to prevent them
• Write a SIGCHLD handler that reaps all children
• Explain the full path of Ctrl+C: keystroke → Ghostty → PTY → kernel → SIGINT → process group
• Build a pipeline (ls | grep foo | wc) with proper fd cleanup in the parent
• Explain why open() returns 3, not 0 (lowest available fd)