Process-Related System Calls

14.1 What Is a Process — Program in Execution

14.1.1 Formal and Plain-Language Definition

A process is a program in execution. Installing a program — a browser, a software tool, an antivirus — does not start it. Execution begins when the program is invoked, for example by double-clicking an icon or typing its name on the command line. At that point the operating system assigns CPU time to the program, the CPU fetches instructions one by one from that program and processes them. Because it processes instructions, it is called a process. A widely referenced definition adds a modern qualifier: a process is an instance of a computer program that is being executed by one or many threads. That addition reflects current hardware.

14.1.2 Threads and Modern Multicore Reality

On modern machines there is rarely a single core or a single CPU. Most systems have multiple cores or multiple CPUs, so a program is often built to run in parallel. Parallel means multiple threads execute at the same time. A thread is a part of a process that gets executed on a CPU or on one core of a CPU. It shares the process context but runs its own instruction stream. The process definition therefore says one or many threads to capture this parallelism.

Visual intuition: picture a timeline of wall-clock time on the horizontal axis and cores on the vertical axis. On a single core, threads appear as colored segments interleaved on one row — A runs, then B, then A again. On four cores, four rows are active at once, each row showing a different thread's colored blocks executing in parallel. Takeaway: the same process abstraction maps to either time-sharing or true parallel execution depending on hardware.

Real-world: a video editor that decodes video on one thread, decodes audio on another, and renders the preview on a third, all inside one editing process, demonstrates why the modern definition needs one or many threads.

14.1.3 Composition: Code and Data

A process consists of the executable code that was written and describes what to do, plus the data that code will use while it runs. When a process is created it gets an image in memory that holds code, data, and the bookkeeping needed to execute the code with the data. Understanding code plus data as the in-memory imprint helps to see why creating a process needs extra memory.

Visual intuition: draw the process address space as a vertical bar: text at the bottom (fixed, read-only), then initialized data, then BSS, then a large middle gap for the heap growing upward and the stack growing downward with an arrow on each side showing growth. The PCB sits outside this bar in kernel memory, pointing to the bar with a PID label. Takeaway: code plus data is a contiguous image with bookkeeping that ties it to a schedulable identity.

14.2 The fork System Call — Primary Way to Create Processes

14.2.1 The Need for Process Creation

In Unix-like and Linux-like systems, a running program is already a process. For the system to create more activity it needs a method to make new processes from existing ones. The list of process-related system calls for this discussion includes fork, wait, exec, exit, signal, kill, and raise. The first method in that list, fork, is the primary way to create a new process. The new process is called the child process.

14.2.2 The Web Server Story — Scaling with Child Processes

A concrete picture makes the purpose of fork easy to hold. Consider a web server as a running process whose job is to listen for web requests from clients and serve a response. For simple informational pages such as a tourist site, a request arrives, the server fetches the page and sends it back. That works for light traffic.

Now picture results day for a large exam. Tens of thousands of clients press submit at the same moment, each request carrying a register number that requires a database lookup to build a personal results page. A single server instance cannot handle thousands of simultaneous lookups by itself. Even though each lookup may take only milliseconds, those milliseconds let a queue of ten to fifteen more requests build up.

The classic solution is delegation by forking. As soon as the parent server receives a request it creates a child process that is fully capable of handling that request. The parent hands the request to the child and immediately returns to its waiting state to listen for the next request. The child fetches data, formats the response, sends it to the client that asked, and then ends itself. On the next arrival the parent repeats the pattern: create a child, pass the request, wait for more work. In this way one listening process scales by manufacturing helpers on demand.

Visual intuition: draw a vertical timeline of the parent as a single line with accept points, and at each accept a short branching line appears, runs for a small horizontal segment (the child handling one request), then ends with an X. The parent line stays continuous at the top, never pausing for the branch's work. Takeaway: the parent is a dispatcher, not a worker.

14.2.3 Historical Context Versus Modern Scaling

The web-server-forks-a-child-per-request pattern is described as the older, traditional way. Today services often scale out differently: multiple server instances run in parallel on different machines and a client-facing component called a load balancer spreads incoming work. A simple policy is round-robin: with five servers, request one goes to server one, request two to server two, and so on, wrapping around after server five. Many policies exist, but the point of telling the older fork story is to show where this way of thinking started and why fork exists as a building block.

Real-world: cloud providers still teach the fork-per-request sketch because it maps directly to container-per-request and serverless-function-per-request designs — the names change, the dispatch-then-handle pattern remains.

14.2.4 What the Child Executes by Default and How to Deviate

By default a new child gets a fresh copy of the parent. In memory that means a separate copy of the parent program — the same code and data — and the child begins executing it on its own. That raises a natural worry: will every child just go back to listening like its parent? Usually that is not what is wanted. The child should do something else, such as handling one specific client request. There is a way to deviate from copying the parent blindly: after a fork the child can be told to execute different code. That deviation is where exec enters, discussed later.

Visual intuition: draw the parent memory image as a rectangle labeled SERVER. At fork a second identical rectangle appears next to it with a dotted arrow labeled copy. Immediately after, the child's rectangle is crossed out and replaced with a rectangle labeled HANDLER, while the parent's rectangle stays labeled SERVER. Takeaway: fork clones, then the child diverges.

14.3 Life Cycle of a Process — The Five States

14.3.1 The Five States at a Glance

A process moves through distinct states from start to removal:

• New — the program has been selected to start, for example by double-clicking an icon.
• Ready — memory is available, modules are linked, a process control block has been defined, and the process is loaded and ready to be given the CPU.
• Running — the scheduler has placed the process on the CPU; the processor fetches each instruction, accesses data as needed, and executes instructions one by one.
• Waiting (sometimes called blocked) — the process is paused for an input-output event to finish.
• Terminated — execution is finished, an exit is issued, and resources are returned to the system.

14.3.2 From New to Ready to Running to Terminated

The journey begins in the new state when the system is told to start a program. If memory can be allocated and linking succeeds, the process is admitted and moves to ready. Ready means ready to run on the processor but not yet running. The scheduler then picks the process, gives it the CPU, and the state changes to running.

If nothing interrupts it, execution continues through the program until the last statement, where an exit is issued. That signals that the job is done and the process should be removed from memory with all resources reclaimed. The transition is running to terminated.

Two other departures from running are important. If the process gets interrupted by a timeout — each process is given a time slice — an interrupt causes preemption and the process returns to the ready queue so other work can run and the interrupt can be handled. This is running to ready.

Visual intuition: draw five circles labeled New, Ready, Running, Waiting, Terminated with arrows: New→Ready, Ready→Running (labeled dispatch), Running→Ready (labeled timeout/preempt), Running→Waiting (labeled I/O request), Waiting→Ready (labeled I/O complete interrupt), Running→Terminated (labeled exit). Takeaway: Ready is the only entry to Running.

14.3.3 The Waiting State and the Printer Example

Consider a program that needs to print a document. While running, it requests the printer to take over the job. Keeping the process on the CPU while the printer works would waste the processor. Instead the system moves the process off the CPU into the waiting state and puts it in a waiting queue. The printer prints, the CPU becomes free to run other programs, and the system achieves multiprogramming — many programs making progress over time.

The waiting example was carried fully: the request to print moves the process from running to waiting; the message "please wait until the printing finishes" describes the wait queue; the printer, on completion, sends an interrupt to signal that the job is done; the system then moves the process from waiting back to ready. A frequent point of confusion is why it goes to ready rather than straight to running. While the first process waited, other programs were running. The system cannot just eject a running program. Instead the awakened process re-enters the ready queue so the scheduler can give it the CPU in turn.

14.3.4 Scheduler, Control Block, and Multiprogramming

The ready queue and the waiting queue are managed by the scheduler. When memory is allocated and the process is loaded, a process control block — the operating system's record for that process — is defined. From there the scheduler assigns the CPU to ready processes, handles time-slice expiry, and re-queues waiting processes after their I/O completes. The same flow applies to a tiny job such as adding two numbers and printing them: new, admitted to ready, scheduled to running, then terminated once the last instruction completes.

Visual intuition: sketch the scheduler as a traffic officer at an intersection. Ready queue is cars lined at a green-light lane, Waiting queue is cars parked at a service station off the road, the CPU is the intersection itself, and the officer (scheduler) directs one ready car into the intersection, parks any car whose engine needs a tow, and waves a serviced car from the station back into the ready line. Takeaway: progress comes from keeping the intersection fed while slow service happens off-road.

14.4 Process Identity and How fork Reports Its Result

14.4.1 Process Identifier — The Tracking Handle

The system tracks every live process through a process identifier, abbreviated PID. When a process is created it is given a PID. This integer is the handle the system uses to refer to that specific process in later operations such as waiting for it or sending it a signal.

14.4.2 Fork Signature: No Input, Tri-State Result

The fork system call takes no input parameters. Its reporting behavior is unusual and is worth stating slowly. Every program returns an integer to the system to indicate success or failure of its run. Fork follows that, but with a split outcome:

• If fork cannot create a child, for example when there is not enough memory to copy the parent image, it returns a single negative value. The negative value is the error signal that creation did not go through. One reason highlighted is memory pressure: a child needs a fresh copy of the parent, and without extra memory that copy cannot be made.
• If fork succeeds, it returns two values in total. One is zero, and that zero belongs to the child process. The other is a positive value, and that positive value belongs to the parent. The positive value is the PID of the newly created child.

This two-valued success return is the surprising part: after a successful creation both the parent and the child continue execution and each receives a return from the same fork call.

Visual intuition: draw one dot before the call (the parent). At the call, the dot splits into two dots side by side. Annotate the left dot (child) with 0, the right dot (parent) with a tag like 1692, and put a single crossed dot above them labeled –1 for the error case that stays as one dot. Takeaway: one call, up to two return paths, distinguished by three integer regions.

14.4.3 Why Zero for the Child and a Positive PID for the Parent

The zero tells code that "you are the child." The positive PID tells code that "you are the parent, and this is your child." By testing the returned integer, a program can place child work in one branch and parent work in another. Variables involved: PID of parent $pi{d}_{parent}$ and PID of child $pi{d}_{child}$ where $pi{d}_{child}\in {\mathbb{Z}}_{>0}$ and the child sees $0$. The error case is signaled by a value in ${\mathbb{Z}}_{<0}$.

Visual intuition: draw the fork site as a fork in a road. Signposts after the split read –1 (road closed, stay put), 0 (you are the new side road), and a tagged number like 1692 (you are the original road and that number names the new side road you just opened).

14.5 Fork in C — First Program and Execution Order

14.5.1 Headers and Build Setup

The demonstrations use C. A common header for standard input-output work is needed, and two additional headers are required to use fork and to have access to the type definitions it relies on. One is the Unix standard header and the other is the types header. The compiler used is GCC, the GNU C compiler, which produces an object program from source.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main(void) {
    /* fork demos go here */
    return 0;
}

14.5.2 Code Walkthrough — One Fork Followed by One Print

The minimal example has this shape in the main program:

• include standard I/O, Unix standard, and types headers
• enter main
• call fork with no arguments
• execute a print statement that outputs a line such as "hello world"
• return from main

The key teaching note is that code after the fork is executed by both the parent and the child. The parent existed before the call, the child is created at the call, and from that point onward both continue through the remaining statements.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main(void) {
    fork();
    printf("hello world\n");
    return 0;
}

Visual intuition: write the source vertically from top to bottom. Draw a single line from the top until fork(), then split into two parallel lines leaving the same point, both passing through printf and return. Label the left branch child (0) and the right branch parent (child PID).

14.5.3 Worked Execution — Why Two Hello Worlds and Why Parent First

Running the minimal program produced:

hello world
hello world

with the shell prompt appearing between the two lines in a characteristic way: first line, then the prompt, then the second line just after the prompt, with a newline restoring the prompt on the next enter. Students were asked how many times the print would run. The consensus "two times" was correct. One execution belongs to the parent, one to the child.

A common first guess tried to explain the prompt placement with threads. The correction kept the distinction: this is about processes, not threads. The ordering was then traced. Creating a process is a heavy task: the system must find a fresh region of memory, copy the parent image there, and prepare the child to start. That takes a small but non-zero time. Meanwhile the parent is already loaded and ready, so it reaches the print first, emits the first line, and returns without waiting for the child. The shell prints its prompt because the parent has finished. Slightly later the child finishes preparation, reaches the same print, emits the second line right after the prompt, and returns. The interval is tiny but visible.

An illustration used two runners: one runner is already on the track and can go immediately, while a new runner must be created and must go through a brief starting phase. The head start explains the parent-first order without needing a sleep or explicit wait.

  hello world
  user@vm:~\$ hello world
  user@vm:~\$ 

14.5.4 Build and Run Trace

The run used a fresh Ubuntu environment in a virtual machine. The IP address of the box was shown to connect to it, font size was increased for visibility, and the workflow was: create a source file, compile with GCC to produce an output program named hello, list the directory to confirm the object exists, and run the program. The interleaved prompt behavior described above was observed on execution.

14.6 Multiple Forks — Exponential Process Creation

14.6.1 The 2-to-the-n Rule

When forks are placed in sequence so that every existing process hits the next fork, the number of processes doubles each time. With $n$ forks executed by every process that exists at the point of the call, the total number of processes that reach the final print is:

$$\text{total prints}=2^n$$

where $n$ is the number of fork statements, each fork is of the form $\text{fork}()$, and exponentiation is integer. The number of child processes is one fewer:

$$\text{number of children}=2^n-1$$

because one of the $2^n$ processes is the original parent. The rule was used as a quick check rather than as a full derivation.

• Verbal description: "two to the power n is the number of times you see the print, n is the number of times you have fork."
• Symbol definitions: $n\in {\mathbb{Z}}_{\ge 0}$ is the count of fork statements encountered in sequence; $2^n$ counts all processes that survive to the print.

Visual intuition: draw a full binary tree of height $n$. Level 0 has 1 node (parent). Each edge is a fork. Count leaves at depth $n$: $2^n$ leaves each represent a process that reaches the final printf. Label the path strings: for $n=3$, leaves are ancestor→left/child versus right/parent choices — 000, 001, 010, 011, 100, 101, 110, 111. Takeaway: leaves, not internal nodes, correspond to prints.

14.6.2 Worked Computation with Three Forks

The class examined a program with four print-like statements surrounding three fork calls and worked the numbers in full. Students first guessed "four times." The careful count gave:

• $n=3$
• $2^n=2^3=8$

So eight lines appear. All eight were listed and numbered 1 through 8 on the display. One belongs to the original parent, seven are children. If a question asks how many child processes were created, the answer is $2^n-1=7$. If it asks how many prints came from children only, it is also $2^n-1$. The distinction was stressed because many students answer the child count with $2^n$.

Every child after the first fork can itself become a parent for the next fork. That is why counting is not "three children for three forks" but exponential: child processes also fork.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main(void) {
    fork();   /* n=1 */
    fork();   /* n=2 */
    fork();   /* n=3 */
    printf("hello world\n");
    return 0;
}

14.6.3 PID Hierarchy Demonstration

To make the hierarchy visible, the program was changed to print each process's PID using getpid. Sample output shown had values such as 70, 71, 72, 73, 74, 75, 76, 77 grouped to show parent-child ancestry. The interpretation given was that 70 was an ancestor, 71 was a child of 70, and subsequent IDs branched further, forming a tree. All eight processes printed, confirming the $2^3$ count, and all but one were identified as children.

pid_t pid = getpid();
printf("PID %ld hello\n", (long)pid);

Visual intuition: draw the binary tree of depth three where each internal node is a fork point and each edge labels the child's fresh PID. The eight leaf labels are the eight printed PIDs 70–77. Takeaway: the $2^n$ count is also the leaf count of the fork tree.

14.6.4 Student Questions and Answers

14.7 Distinguishing Parent and Child in Code

14.7.1 Branching on the Return Value

Storing the return of fork in a variable such as pid makes the roles testable:

• if $pid<0$ then an error occurred; no child was created and the error branch can exit with a non-zero status
• if $pid=0$ then this branch is the child; a child block can be opened
• if $pid>0$ then this branch is the parent; the positive value is the child's PID and a parent block can be opened

A common snippet pattern shown was:

• fork and save its result into pid
• print the returned pid value
• if pid less than zero, print an error and exit
• if pid equals zero, enter a block that prints "I am the child with PID ..." and then indicates the child is exiting
• if pid greater than zero, enter a block for the parent and, depending on the experiment, either wait for the child or not

The point of saving the positive PID in the parent is that later system calls such as waitpid can be given that specific child to wait for.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void) {
    pid_t pid;
    pid = fork();
    printf("fork returned %ld\n", (long)pid); /* diagnostic line */
    if (pid < 0) {
        fprintf(stderr, "fork failed\n");
        return 1;
    }
    if (pid == 0) {
        /* child block */
        printf("I am the child with PID %ld\n", (long)getpid());
        printf("the child process is exiting\n");
        return 0;
    }
    if (pid > 0) {
        /* parent block — pid is the child's PID for waitpid */
        printf("I am the parent waiting for the child to end\n");
        /* wait(&status) or waitpid(pid, &status, 0) here */
    }
    return 0;
}

Visual intuition: draw a diamond after fork with three outgoing arrows labeled –1 (error), 0 (child box), and +N (parent box holding the child's tag). Takeaway: one call, three labeled exits, immediate pruning of who executes what.

14.7.2 Worked Output with 1691 and 1692

A demonstration program followed that pattern, with the wait call initially commented out. Its run produced lines including "I am 1691" and "fork returned 1692" and also "fork returned 0". The reading given was:

• "I am 1691" came from the statement before or just after the fork that printed the current process's identity; 1691 identified the parent.
• "fork returned 1692" is the parent view: the positive return is the child's PID, 1692.
• "fork returned 0" is the child view: zero marks the child.
• Additional messages were "I am the child with PID 1692" and "the child process is exiting" from the child branch, and from the parent branch a line such as "I am the parent waiting for the child to end" when waiting was enabled.

The trace emphasized that after fork every statement beyond that point runs twice: once in the parent context where fork returned a positive PID, and once in the child context where it returned zero. That is why two "fork returned" lines appear when creation succeeds, versus a single error line when it fails.

Visual intuition: print two side-by-side timelines: Left timeline (PID 1691, parent) shows fork → 1692 → parent branch; Right timeline (PID 1692, child) shows fork → 0 → child branch. Connect the fork moment with a horizontal clone line from left to right. Takeaway: one source line becomes two printed confirmations.

14.7.3 Demonstration Variants

The same source was compiled and run multiple times under GCC, with directory listings used to confirm that programs such as hello were built. The focus remained on the printed PID values and the branch messages, not on C syntax details.

14.8 Orphan and Zombie Processes

14.8.1 Orphan — Child Outlives Its Parent

An orphan process was described as a child that keeps running after its parent has already finished and terminated. In the demonstration without a wait, the parent printed, returned, and the shell gave back its prompt while the child was still starting and then printing afterward. Because the parent was done, the child had no parent to return to. The human analogy used was simple: an orphan has no parent.

14.8.2 Zombie — Child Waits for a Busy Parent

A zombie process was described as the opposite asymmetry. Here the parent is very busy — not lazy but occupied — and the child finishes its job and wants to return its exit status. If the parent is too occupied to collect that status, the child remains in a zombie state: it is done but cannot be fully reaped because nobody is taking it back. The wording used was "it does not know what to do because nobody is taking it" and "a parent so busy it cannot accept the return status."

  PID  PPID STAT COMMAND
  1700  1200 S    parent_busy
  1701  1700 Z    child [defunct]

14.8.3 The Init Process as Adopter

Orphan processes do not remain unowned. They are taken over by the very first process of the Unix or Linux system, often described as the init process. That process collects such orphans and handles their final cleanup. This adoption was presented as the system's answer to children whose parents have already exited.

Visual intuition: picture a family tree where the parent node disappears. Its child nodes are not deleted — dashed adoption arrows reconnect them to the root node labeled 1/init at the top. Leaves that have already finished (zombies) are removed when the root's wait prunes them; running orphans remain as live adopted leaves.

14.9 Wait and Waitpid — Synchronizing Parent and Child

14.9.1 Purpose and Variants

The wait family exists so a parent can pause until its children finish. Two forms were discussed:

• a simple wait with a null parameter, which means "wait for my own child" — any child of the caller
• a more specific waitpid that takes a PID and a status location, which means "wait for that particular child"

A parent may have created multiple children. With the specific form it can name which child it is waiting for by passing that child's PID. The status parameter is where the child's exit information is collected.

Visual intuition: draw the parent timeline with a bold bar labeled wait/waitpid blocking the parent line. The child's timeline runs concurrently, ends with exit(status), and a dotted arrow labeled SIGCHLD notifies the parent; the wait bar then unblocks and the parent continues. Takeaway: without the bar the parent would race ahead and leave an orphan; with it they rendezvous.

14.9.2 Demonstration — Without Wait Versus With Wait

The same PID-branching program was run twice to contrast the two behaviors.

• Without wait, i.e., with the wait line commented out: the parent printed first, returned, the shell prompt appeared, then the child's lines appeared after the prompt. The interpretation was that an orphan pattern had been created: the parent did not wait, so the child ran without a waiting parent.
• With wait restored and with a message "I am the parent waiting for the child to end": the parent printed its identity line "I am 1771", printed "fork returned 1722" as the child's PID, printed "fork returned 0" from the child's perspective, printed that it was waiting, and then paused. The child then printed "fork returned 0", "I am the child with PID ..." and "the child process is exiting." Once the child exited, its return status was collected by the parent, and only then did the parent exit and print a final confirmation. No orphan was created in this version.

The displayed sequence for the waiting run was summarized as: parent identity, parent view of fork, child view of fork, parent waiting message, child executing and exiting, parent collecting status and exiting. This was presented as the direct answer to the question "why use wait at all."

I am 1771
fork returned 1722        /* parent view — positive child PID */
fork returned 0            /* child view — zero */
I am the child with PID 1722
user@vm:~\$                  /* shell prompt returns because parent 1771 did not block */
the child process is exiting /* child 1722 prints after prompt — orphan pattern */

I am 1771
fork returned 1722          /* parent view */
fork returned 0              /* child view */
I am the parent waiting for the child to end  /* parent before blocking */
fork returned 0              /* child re-entry if diagnostic before branch; duplicates seen in demo */
I am the child with PID 1722 /* child branch */
the child process is exiting  /* child calls exit */
[parent wait returns, status collected]       /* kernel delivers SIGCHLD + status */
parent: child I waited for has returned (wait == 1722) /* optional check */
parent completing its job

14.9.3 Waiting for a Specific Child and Status Handling

When waitpid is given a specific PID, that PID is the positive value returned by fork in the parent. A status variable is supplied by address so the system can fill it with the child's exit code. A check that compares the return value of waitpid with the PID can confirm that "the child I waited for is the one that came back." Passing null for the status was described as the choice when the caller does not need the detailed exit reason and just wants the synchronization.

pid_t pid = fork();
int status;
...
if (pid > 0) {
    printf("Parent waiting for child %ld\n", (long)pid);
    if (waitpid(pid, &status, 0) != pid)
        err_sys("waitpid error");
    /* optionally decode status */
    if (WIFEXITED(status))
        printf("child exited normally, exit = %d\n", WEXITSTATUS(status));
    else if (WIFSIGNALED(status))
        printf("child killed by signal %d\n", WTERMSIG(status));
}

14.10 The exec Family — Replacing the Child Image

14.10.1 The Idea — Doing Something Different from the Parent

By default a child starts with a copy of the parent program. Often that is not what is wanted. Recall the web server passing a client ID to a backend job: the child should run business logic that fetches from a database, not just loop listening for connections. Exec provides the deviation. After a fork, the child can invoke an exec call to replace its current program image with a new program. The parent code that was copied is discarded and the child begins executing the named program instead.

Visual intuition: picture the child as a room initially furnished as a copy of the parent's room (the fork copy). exec empties that room completely — walls repainted, furniture swapped — and the same room number now houses the handler. The parent's room across the hall remains unchanged.

14.10.2 The Six Variants and the Used Form

Exec exists in six variants that differ in how arguments and environment are supplied and how the program is located. Details of all six were not pursued; one representative form was used. That form takes the name of the program to run plus two additional parameters: an argument vector and an environment vector. In the class example both were set to null, meaning no extra arguments or environment were forwarded. The example name used in the listing was "child" as the program the new image should run.

14.10.3 Parent and Child Programs Walkthrough

Two separate source files were presented:

• The parent program: prints an opening line such as "Parent: hello world", calls fork, saves the result into a variable, tests whether the result is zero to recognize the child, and if it is the child, calls exec with the argument and environment both null and with program name child. The other branch — the parent branch where the return is positive — prints that it is waiting, then calls waitpid on the child's PID with a status location, compares the returned value with the saved PID, and prints a message that the child it waited for has returned before finally printing that the parent is completing its job.

• The child program: defines variables, runs loops that do calculations, then prints lines such as "I am the child. I have completed the work and I am quitting now." Its return status will travel back to the parent through the wait status.

The web-server mapping was repeated explicitly: the register number and any other client data would travel in the argument and environment vectors that exec carries into the new program; the name field names the backend program to run.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void) {
    pid_t pid;
    int status;
    printf("Parent: hello world\n");
    pid = fork();
    if (pid == 0) {
        /* child path — replace with handler */
        execl("./child", "child", (char *)NULL); /* arg + env both NULL conceptually */
        perror("exec failed");
        return 1;
    }
    if (pid > 0) {
        printf("Parent waiting for the child to complete\n");
        if (waitpid(pid, &status, 0) == pid) {
            printf("the child process I waited for has been written back\n");
        }
        printf("parent completing its own job\n");
    }
    if (pid < 0) {
        perror("fork failed");
    }
    return 0;
}

#include <stdio.h>
int main(void) {
    int i, sum = 0;
    printf("hello world\n"); /* same greeting but from the new image */
    for (i = 0; i < 100; i++) sum += i;
    printf("I am the child. I have completed the work and I am quitting now.\n");
    printf("Work completed. Bye for now.\n");
    return 0;
}

Visual intuition: draw the child's control-flow arrow reaching exec where it vanishes and reappears at the top of a second flowchart labeled CHILD PROGRAM, while the parent's arrow arcs around exec to reach waitpid. Takeaway: same PID, different program, parent patiently blocked.

14.10.4 Compilation and Execution Trace

Both files must be built before the joint run. The steps shown were: compile parent.c into an executable named parent, compile child.c into an executable named child, ensure the child executable name matches the name string used in the parent's exec call, otherwise the lookup will fail, and then run the parent executable.

The joint run was traced in order:

1. Parent starts and prints "Parent: hello world."
2. Parent reaches fork, creates the child, saves its PID.
3. Parent branch recognizes a positive PID and prints "Parent waiting for the child to complete" and blocks in waitpid.
4. Child branch recognizes zero, calls exec, is replaced by the child program image, and starts running that program.
5. Child program prints "hello world" from its own code, runs its calculations, prints completion lines including "Work completed. Bye for now."
6. Child quits; its exit status is delivered to the waiting parent.
7. Parent resumes, prints that the child process it waited for has been written back, and prints that it is now completing its own job.

\$ gcc -Wall -o parent parent.c    # create executable 'parent'
\$ gcc -Wall -o child child.c      # create executable 'child' — must match execl's "./child"
\$ ls -l
-rwxr-xr-x 1 user user  ... parent
-rwxr-xr-x 1 user user  ... child
-rw-r--r-- 1 user user  ... parent.c
-rw-r--r-- 1 user user  ... child.c
\$ ./parent
Parent: hello world
Parent waiting for the child to complete
hello world
I am the child. I have completed the work and I am quitting now.
Work completed. Bye for now.
the child process I waited for has been written back
parent completing its own job
\$ echo \$?
0

14.10.5 Student Questions and Answers

14.11 Signals — Asynchronous Events

14.11.1 What a Signal Is and Why It Matters

A signal was defined simply as an event. When the event occurs it notifies a process, or a thread within it, that something important has happened. After receiving a signal the process must take some action based on what was received. It does not act instantly in the middle of an instruction; it pauses what it was doing and then handles the signal. Signals were framed as a core part of inter-process communication.

Visual intuition: draw a straight time arrow for a process executing instructions as ticks. At a random tick a vertical arrow labeled SIGINT drops onto the timeline; the process line bends down into a handler box, then bends back to the same point on the straight arrow and continues. Takeaway: the signal interrupts the flow but does not rewrite it.

14.11.2 Inter-Process Communication Context

Two contexts were linked. In the earlier exec example the parent and child were two separate programs coordinating: the parent launched the child and waited. In a single program with a fork, the parent and child are two processes sharing the same original program space. Both are cases of inter-process communication — multiple processes that need coordination. Signals offer a light-weight way to notify between them.

Real-world: a shell that forks a foreground job sleep 100, then forwards its own SIGINT (Ctrl+C) to that job via kill, is using signals as IPC so the foreground job, not the shell, actually dies from the interrupt.

14.11.3 Everyday Example — Infinite Loop and Ctrl+C

A plain example was an allocation program that contains a logic error and enters an infinite loop. Left alone it would exhaust memory and cause problems. The way to stop it interactively is the key sequence Ctrl + C. That sequence generates a signal — an event sent to the program — and the program is expected to react by stopping. The point was that without an explicit notification path, a runaway loop would have no clean way to be told to exit; signals supply that path.

#include <stdlib.h>
int main(void) {
    while (1) {
        malloc(1024*1024); /* logic error — never freed, never tested */
        /* ... eventually exhausts memory */
    }
    return 0;
}

14.12 Signal Handling Mechanics

14.12.1 Registration — Header and the signal Call

To handle a signal a program must include the signal.h header (signal.h), which defines the available signal numbers. It must register a handler before the signal matters. Registration uses the signal system call with two pieces of information: which signal to watch for and which function to call when it arrives. A signal number such as SIGINT — the interrupt that Ctrl + C generates — was used. A handler name such as sig_handler, defined by the programmer, was passed as the second argument. The naming is free as long as the name registered and the name defined match; calling it SIG_hand or sig_handler is a choice, not a fixed spelling.

#include <signal.h>
void sig_handler(int sig) { /* sig is the signal number, here SIGINT */
    /* work that is safe in a handler */
}
int main(void) {
    signal(SIGINT, sig_handler); /* arm before the loop matters */
    /* loop that can be interrupted */
}

14.12.2 Handler Function and the Infinite Loop Demo

The demo program had two parts. A handler function defined what to do on a SIGINT: in the example it printed a line such as "Inside handler function" and executed a call that re-registered the signal for its default behavior. The main program registered the handler once at startup, then entered an infinite loop with no exit condition, incrementing a counter and printing a line such as "I am in the main function: infinite loop" once per second with a one-second delay.

Running the program showed the loop printing each second. The first time Ctrl + C was pressed, control transferred into the handler. The handler printed its inside message, called the registration that asks for default handling onward, and then returned to the main loop, which continued printing.

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void sig_handler(int sig) {
    printf("Inside handler function\n");
    signal(SIGINT, SIG_DFL); /* next SIGINT uses default termination */
}
int main(void) {
    signal(SIGINT, sig_handler);
    while (1) {
        printf("I am in the main function: infinite loop\n");
        sleep(1);
    }
    return 0;
}

14.12.3 Default Action, Re-registration to SIG_DFL, and the Two-Ctrl+C Behavior

The two-press behavior was then explained. The first press does not kill the program in this demo. The default action for SIGINT is to end the program, but the program initially overrides that by registering its own handler. So the first SIGINT is caught and handled by the custom function. Inside that handler the line with SIG_DFL — default — re-registers the signal to mean "use the default function from now on." The abbreviation DFL was expanded as default. Because of that re-registration, the second press of Ctrl + C now triggers the system's built-in action and the program stops immediately. The contrast was stated as: first Ctrl + C handled to print and switch to default, second Ctrl + C executes the default termination.

Visual intuition: picture the SIGINT disposition as a switch with two positions: CUSTOM (points to sig_handler) and DEFAULT (points to a trapdoor). Initially set to CUSTOM, the first press flips the switch to DEFAULT and briefly runs the custom box; the second press hits the DEFAULT side and the trapdoor opens.

14.12.4 Exit Status — Normal Zero Versus 130

The shell's record of how a program ended was shown with the special shell variable that holds the exit status of the last command. A normally ended program such as a plain hello run left that variable at zero, meaning normal termination. The signal-handler program left it at 130 after being ended with SIGINT, meaning it did not end normally but was interrupted. The value 130 was shown twice: once after a normal hello run to show zero, once after killing via Ctrl + C to show 130, and again after a full repeat of the handler demo. The difference was summarized as zero for normal return, non-zero such as 130 when a signal caused the end. The spoken phrase "dollar question" was a reference to that shell variable.

Real-world: diagnosing whether a process ended on its own or was killed, using exit codes in scripts.

14.13 Raising and Sending Signals — raise and kill

14.13.1 Signatures and Semantics

Both functions that send signals are declared in the signal.h header (signal.h). Their signatures were contrasted side by side:

• raise takes a single parameter, a signal number such as SIGUSR1. It sends that signal to the calling process itself. The phrasing used was "to itself." On success it returns zero; on failure it returns a non-zero value. The outcome is binary and local.

• kill takes two parameters, a PID and a signal number. It sends the signal to the process, or to the group of processes, named by that PID. The PID field names the target. So kill can address "another process" by name. Success and failure reporting follows the same zero versus non-zero pattern.

A common mix-up of the name "race" for "raise" was present in the spoken track; the intended call is raise. Similarly, "signal user one" refers to SIGUSR1, a user-defined signal number available for program-to-program messages.

Visual intuition: draw raise as a U-turn arrow looping inside one process box back to its own handler, and kill as a straight arrow from a sender box to a target box labeled by PID. Both arrows are tagged with the same signal number SIGUSR1. Takeaway: same event ID travels — the difference is whether a PID must be named.

14.13.2 In-Process Signaling with raise

A minimal in-process example registered a handler for SIGUSR1, then inside main called raise with that same signal number. The order in output was: "Inside main function", then after raise the handler printed "Inside handler function", then control returned and the main printed its continuation line before exiting. The trace shows that raise does not jump to a different process; it causes the same process to handle the signal and then continue. A note was made that the number used in registration and the number passed to raise must match.

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void h(int sig) { printf("Inside handler function\n"); }
int main(void) {
    signal(SIGUSR1, h);
    printf("Inside main function\n");
    raise(SIGUSR1);          /* same process, same SIGUSR1 */
    printf("back in main after handler\n");
    return 0;
}

14.13.3 Cross-Process Signaling with kill and getpid

The counterpart replaces raise with kill while keeping the same handler. Inside main the program fetched its own PID with getpid, then called kill with that PID and SIGUSR1. Output order remained the same — main, handler, main — because the target happened to be itself. The difference is the interface: kill requires an explicit PID even when sending to self, whereas raise needs only the signal.

The point of showing the self-targeted kill was as a stepping stone. The same call shape is used when the target is genuinely another process; the PID can be any known value, such as a child's PID obtained from fork or a parent's PID obtained from getppid.

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
void h(int sig) { printf("Inside handler function\n"); }
int main(void) {
    pid_t mypid;
    signal(SIGUSR1, h);
    printf("Inside main function\n");
    mypid = getpid();
    kill(mypid, SIGUSR1);   /* explicit PID vs raise's implicit self */
    printf("back in main after handler\n");
    return 0;
}

14.13.4 Worked Traces for Both Variants

Two traces were displayed:

• raise variant: registration for SIGUSR1 in main, raise of SIGUSR1, handler prints and returns, remaining main lines execute.
• kill variant: registration in main, getpid into a variable, kill with that variable and SIGUSR1, handler prints and returns, remaining main lines execute.

In both, pressing no external keys is needed; the signal is generated by the program itself.

Inside main function
Inside handler function
back in main after handler

14.14 Parent-Child Bidirectional Signaling

14.14.1 Setup — Two Handlers, Fork, and Pause

The last demo put everything together: two signal handlers, one named for the parent and one for the child, a fork to create both roles, registration of each handler in its respective branch, and calls to pause and sleep to park a process while it waits for a signal. The includes again covered standard I/O, the Unix standard header, types, and signal handling. The parent and child handlers had distinct print messages so the observer could tell which ran.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>
void parent_handler(int sig) { printf("Received a response signal from the child\n"); }
void child_handler(int sig)  { printf("Child received a signal from the parent\n"); kill(getppid(), SIGUSR1); }
int main(void) {
    pid_t pid;
    pid = fork();
    if (pid == 0) { /* child */
        signal(SIGUSR1, child_handler);
        printf("Child waiting for signal\n");
        pause(); /* wait for parent's SIGUSR1 */
        /* after handler returns, process continues / exits */
    } else if (pid > 0) { /* parent */
        signal(SIGUSR1, parent_handler);
        sleep(1); /* give child time to reach pause */
        printf("Parent started sending a signal to the child\n");
        kill(pid, SIGUSR1); /* parent to child — pid is child's PID */
        pause(); /* wait for child's reply */
    }
    return 0;
}

14.14.2 Step-by-Step Message Exchange

The order of operations traced was:

1. Main calls fork. Two execution streams now exist. The original parent keeps its parent identity and holds the positive child PID; the new child sees zero.
2. In the child branch, register the child handler for SIGUSR1. Print "Child waiting for signal" and enter pause, which blocks until a signal arrives.
3. In the parent branch, register the parent handler for SIGUSR1, then sleep briefly to give the child time to reach its pause.
4. Parent sends SIGUSR1 to the child using kill with the child's PID. This is the positive PID the parent received from fork.
5. The child's handler runs. It prints a line such as "Child received a signal from the parent." Inside that handler the child sends a reply signal back to its parent using kill with getppid and SIGUSR1. The parent's PID is obtained by the getppid call; no hard-coded value is needed.
6. The parent's handler runs in response. It prints a line such as "Received a response signal from the child" and then the parent proceeds to exit.

The roles of getpid and getppid were highlighted: getpid returns the caller's own PID, getppid returns the caller's parent's PID. In that reply step, getppid is how the child learns whom to answer.

Visual intuition: draw two vertical lifelines. Child lifeline shows SIGNAL ARM → PRINT waiting → PAUSE block (horizontal wait bar). Parent lifeline shows SIGNAL ARM → SLEEP bar → arrow to child's lifeline labeled SIGUSR1 (first crossing) → PAUSE block. Child lifeline then shows handler box with a return arrow back to parent's lifeline labeled SIGUSR1 (reply). Takeaway: two crossings, child first, parent second, each arrow carries the same signal number but a different PID argument.

14.14.3 Observed Output and Control Flow

The observed console lines were summarized as, in order: a line indicating the child was created and now pausing, a line that the parent started sending a signal to the child, a line that the child received the signal from the parent, and a line that the parent received the response from the child before exiting. The trace was shown twice to confirm that the child handler always runs first — the parent is the initiator — and the parent handler runs second as the reply. Waiting, sleeping, and pausing were presented as the reason the order is stable in the demo even though process scheduling is normally flexible.

Child waiting for signal
Parent started sending a signal to the child
Child received a signal from the parent
Received a response signal from the child

14.14.4 Student Questions and Answers

Exam Guidance Summary

• A few system calls related to process are the focus: fork, wait, exec, exit, signal, kill, and raise. Be ready to state the purpose of each and to trace programs that combine them. The lecture pairs creation (fork/exec) with rendezvous (wait/waitpid) and notification (signal/kill/raise); any trace question can combine at least two of these families.

• Fork details to remember: no input parameters; on failure a single negative value; on success zero in the child and a positive PID (the child's PID) in the parent; code after fork runs in both; creating a process is heavier than creating a thread. The tri-state pid_t fork(void) contract — negative error versus zero child versus positive parent PID — is the single most recalled fact for this exam segment.

• Counting with multiple forks: total processes that reach a final statement equal $2^n$ where $n$ is the number of forks; child count equals $2^n-1$. Distinguish total prints versus prints coming only from children. For $n=3$, total prints 8, children 7; the demo's PID hierarchy 70 to 77 was the concrete evidence for that count.

• Distinguishing branches: save the fork return into a variable pid and branch with pid < 0 for error, pid == 0 for child, pid > 0 for parent. The positive value in the parent is the handle to name that child in later waitpid calls. A frequent error is to put parent work inside the == 0 arm.

• Orphan versus zombie: orphan is a child whose parent has already terminated; zombie is a child that has finished but whose parent is too busy to collect its exit status. Orphans are adopted by the system's first process (often described as init with PID 1, now launchd/systemd on newer systems). The shell-prompt interleaving in section 14.5 is the visual symptom of the orphan window when no wait was used.

• Wait family: null-parameter wait means wait for own child; waitpid with a specific PID and a status location waits for that child and collects its exit information. Without wait, orphans can appear; with wait, the parent blocks until the child can be reaped. Passing NULL for the status discards details but still provides the blocking rendezvous; the encoding is decoded with WIFEXITED/WEXITSTATUS/WIFSIGNALED/WTERMSIG.

• Exec: used after fork when the child should not execute the parent program; replaces the child's image with a named program. Six variants exist; the example used the form with program name plus argument and environment both set to null. Ensure the executable name matches the string used in the exec call — "child" in the source must be a real file named child after gcc -o child child.c.

• Signals: a signal is an event that notifies a process that something important happened; the process pauses its current work and handles it. SIGINT corresponds to Ctrl+C. Handling requires including signal handling definitions and registering a handler via signal with a signal number and handler name. SIG_DFL means restore the default handling. In the demo, the first Ctrl+C was caught by the custom handler and re-registered to default; the second Ctrl+C ended the program.

• Exit status: normal termination leaves the shell's last-status variable at zero; termination by SIGINT left it at 130 in the demonstrations. Refer to that variable without relying on printed shell symbols and remember the two typical values shown. The 130 is commonly 128 + SIGINT(2) — the shell's way of marking a signal death.

• The last syllabus topic on linker and loader was stated as skipped and not part of the examination. The process-related system calls and their demonstrations are the examinable core. Do not spend revision time on linking details for this paper; every exam question in this block will name or trace fork, wait, exec, signal, kill, or raise (plus exit).

Key Industry Applications

• Web server scaling — a parent listener that forks a child per request so the child can fetch database data for a single client register number and build a response while the parent stays available for new arrivals; useful for bursty traffic such as large-scale results publication. This pattern appears in classic Unix inetd-style services and in teaching examples of fork followed by per-client handling before returning to accept.

• Load balancing as a modern complement — a front-end spreads requests across many server instances running on many machines, for example with a round-robin policy of request one to server one, request two to server two, wrapping around; illustrates the shift from per-request forking to horizontal scale-out. Cloud load balancers, Kubernetes service meshes, and CDN edge dispatchers all generalize the same idea: the dispatcher stays hot while workers scale out, with policies beyond round-robin such as least-connections and latency-aware routing.

• I/O-driven design — moving a printing job from running to waiting while the printer works, achieved multiprogramming and explained why waiting processes return to ready before running. The same waiting-state reasoning appears in file-system workloads, database write-behind, and network-driven microservices where latency is hidden by keeping the CPU fed with other ready processes.

• Daemon and helper patterns — parent creates a child with fork, replaces the child's image with a handler program via exec, passes client-specific data via argument and environment vectors, and collects completion via waitpid. Cron jobs, build-system helpers, and container entry-point shims all follow this fork/exec/wait lifecycle.

• Robustness and diagnosis — using PID values to identify parent versus child, watching for orphans adopted by the init process and for zombies left by busy parents, and using wait variants to avoid them. Dashboards that scrape ps for Z (zombie) counts and PPID 1 orphans, plus supervisor patterns like double-fork to avoid zombies, are the production face of sections 14.8–14.9.

• Interactive control — Ctrl+C as SIGINT to stop a runaway allocation loop, distinguishing a normal exit from a signal-induced exit by its exit status of 130 versus 0. Shell scripts test \$? after foreground jobs, and terminal job control (SIGTSTP, SIGCONT) builds on the same handler-plus-SIG_DFL ideas shown in section 14.12.

• Lightweight inter-process notification — raise to signal within the same process and kill with a specific PID to signal a different process, including the bidirectional parent-to-child and child-to-parent exchange using kill with a child's PID and kill with getppid. Coordinator-worker patterns use this to wake a pause()-blocked helper, to implement heartbeats via SIGUSR1/SIGUSR2, or to notify a parent of progress without a pipe, as demonstrated in the final paired demo where each direction carried the same SIGUSR1 with a different PID target.