Design Process Control Block (PCB): struct process

Topic Overview

The PCB Is the Process

Every runnable entity in the kernel is described by a Process Control Block. It is not a metaphor: schedulers, signal delivery, and /proc readers all walk the same struct fields. Linux calls it task_struct; you will name yours struct process, but the responsibilities match.

Fields Worth Getting Right

A practical PCB for this curriculum:

• Identity: pid, ppid, command name
• CPU state: saved registers, kernel stack pointer, program counter
• Scheduling: state enum, priority, time slice remaining
• Resources: open file table, exit status, child list

For example, when PID 42 blocks on a pipe read, its state moves from RUNNING to BLOCKED and the scheduler must not select it until the read completes.

Why This Matters in Production

The struct you're designing mirrors Linux's real task_struct in sched.h, which has grown to hundreds of fields and is why /proc/[pid]/status can expose dozens of process attributes to tools like ps and top. Getting the fork()-copy semantics right here matters in production: forgetting to reset a field like open file descriptors is exactly the kind of bug that caused real fd-leak incidents in forking servers.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will design and populate struct process and helper functions to allocate, find, and free entries. The PCB you build here is reused by later tasks on context switch and wait(), so treat field layout as a long-lived API.

Your Task

Design a process control block and the state machine that drives it. Each PCB holds identity (pid, parent, name), scheduling data (state, priority, the event it is blocked on), accounting (CPU time, wait time, voluntary and involuntary context switches), resources (a small file-descriptor table), and its exit status. Commands move processes through the classic five-state model and refuse any transition the model does not allow.

Input

cCopy
Loading…

State machine

• create gives pids 1, 2, 3… (at most 16 processes). The new process has parent 0 and fds 0-2 open as stdin, stdout and stderr.
• fork (the parent must be RUNNING) copies the whole PCB, including the name, priority and open files. The child gets a new pid, parent = PID, state READY, and zeroed time and switch counters.
• tick N adds N to the CPU time of the RUNNING process and to the wait time of every READY process.
• open uses the lowest free fd (0-7). It fails with EMFILE when all are used, and a TERMINATED process cannot open files. close of an fd that is not open gives EBADF.

Output

cCopy
Loading…

A TERMINATED process shows (exit code N) after its state, and a process with no files shows open files: none. Other messages are pid P: close F, pid P: open PATH -> EMFILE, pid P: close F -> EBADF and create NAME: process table full.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Put all per-process data in one struct. Implement fork as a struct copy followed by fixing the fields that must differ.
2. Check every transition against the table, and report the offending state in the error message.

Hidden tests cover every illegal transition, dispatch while another process is running, preempt and wake cycles with CPU and wait accounting, fd reuse after close, EMFILE and EBADF, exit codes and the files closed on exit, fork copying open files, and unknown pids.