10. Processes

Process IDs and Families#

Each process has a positive integer process ID, or PID. It also has a parent PID:

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main(void) {
	printf("pid: %d\n", (int)getpid());
	printf("parent: %d\n", (int)getppid());
	return 0;
}

PIDs are recycled after processes terminate, so a PID is not a permanent identity. Processes form a changing parent-child hierarchy. A parent can create children; on Unix-like systems, if a parent terminates while a child continues, the child is reparented to an appropriate system process or subreaper which can eventually reap it.

flowchart TD
    INIT["system process"] --> SHELL["shell"]
    SHELL --> EDITOR["editor"]
    SHELL --> PROGRAM["your program"]
    PROGRAM --> CHILD1["child process"]
    PROGRAM --> CHILD2["child process"]

Environment Variables#

Environment variables are strings of the form name=value supplied to a process. Common examples include:

Shell syntax can set a variable for the current shell and its future children:

export STATUS=great

In C:

#include <stdlib.h>

const char *home = getenv("HOME");
if (home != NULL) {
	printf("home: %s\n", home);
}

if (setenv("STATUS", "great", 1) == -1) {
	perror("setenv");
}

getenv() returns NULL when the name is absent. Do not pass that directly to %s.

The entire environment is available through environ on POSIX systems:

extern char **environ;

for (size_t i = 0; environ[i] != NULL; i++) {
	puts(environ[i]);
}

Environment variables are inherited as process state; they are not global variables shared live between processes. Changing a parent's environment after a child has been created does not retroactively update the child's copy.

Some systems also allow main(int argc, char *argv[], char *envp[]), but POSIX does not standardise that third parameter. environ and getenv() are the course's more portable interfaces.

Inspecting Processes from the Shell#

Unix tools expose different views of running processes:

These are programs which use operating-system interfaces themselves. They are not privileged windows into magical state; the kernel decides which process information and operations the caller is permitted to access.

Multitasking and Context Switches#

Many processes appear to run simultaneously. On one CPU core, the OS can create this illusion by running one process for a short time, saving its state, then restoring another process's state. This handover is a context switch.

flowchart TB
    A1["Process A"] --> B1["Process B"] --> C1["Process C"] --> A2["Process A again"]

A scheduler is the part of the kernel which chooses which ready process or thread receives a CPU next. A time slice is the short interval for which it may run before a timer gives the scheduler another chance to choose. A process blocks when it cannot make progress yet—for example, while waiting for keyboard input—so the scheduler can run something useful instead of wasting that CPU time.

A process may therefore stop running because its time slice ended, because it blocked waiting for I/O, or because another scheduling decision was required. The scheduler balances responsiveness, fairness, throughput and other requirements. With multiple cores, some processes can genuinely run in parallel; see Concurrency and Threads.

exec: Replace the Current Program#

The exec family loads a new program into the current process. It does not create another process.

#include <unistd.h>

int execve(const char *path, char *const argv[], char *const envp[]);

On success:

• the process keeps its PID;
• a new program image replaces its old code, globals, heap and stack;
• open file descriptors normally survive unless marked close-on-exec;
• execution begins in the new program;
• execve() does not return.

extern char **environ;

char *arguments[] = {"/bin/echo", "good-bye", "cruel", "world", NULL};
execve("/bin/echo", arguments, environ);

// Reaching this point means execve failed.
perror("execve");
return 1;

argv[0] conventionally names the program, and both argv and envp must end with a null pointer.

Convenience variants differ in how arguments and environments are supplied. For example, execv() inherits the existing environment, while execvp() also searches directories in PATH. Check an assignment's restrictions before choosing one.

flowchart LR
    BEFORE["PID 412<br/>running your program<br/>old address space"] -->|"execv('/bin/date', ...)"| AFTER["PID 412<br/>running /bin/date<br/>new address space"]

fork: Duplicate the Current Process#

fork() creates a child process by duplicating the calling process:

pid_t fork(void);

Both processes return from the call, but receive different results:

• -1 in the original process means creation failed;
• 0 is returned in the child;
• the child's PID is returned in the parent.

pid_t pid = fork();

if (pid == -1) {
	perror("fork");
	return 1;
} else if (pid == 0) {
	printf("child: pid=%d\n", (int)getpid());
} else {
	printf("parent: child pid=%d\n", (int)pid);
}

After fork(), the scheduler may run either process first. Do not infer parent-before-child ordering from the order of the branches in the source code; use synchronisation such as waitpid() when an order is required.

The child begins with a copy of the parent's memory. Afterwards, ordinary writes to variables affect only that process's copy:

int x = 10;
pid_t pid = fork();

if (pid == 0) {
	x = 99;
	printf("child x = %d\n", x);
} else if (pid > 0) {
	printf("parent x = %d\n", x); // still 10
}

File descriptors are inherited too. An open file description is the kernel record behind one particular opening of a file; it stores state such as the current offset and status flags. Parent and child descriptors derived from the same pre-fork() descriptor refer to the same open file description, so they share an offset. This makes communication and redirection possible, but unsynchronised writes can interleave. File Systems develops the complete descriptor-table model.

Practice: Quick Checks#

1. What are the three classes of return value from fork(), and which process sees each successful value?
2. Does execv() create a process? Name two pieces of process state which survive a successful execv() and two which are replaced.

Counting Forked Processes#

Every process which reaches an unconditional fork() creates one additional process. Therefore:

fork();
fork();
fork();

produces 2^3 = 8 processes, because the first fork leaves two processes to execute the second, and then four execute the third.

flowchart TD
    S["start<br/>1 process"] --> F1["after fork 1<br/>2 processes"]
    F1 --> F2["after fork 2<br/>4 processes"]
    F2 --> F3["after fork 3<br/>8 processes"]

Conditions alter the count. Draw a process tree and follow exactly which branches reach each call.

Worked trace: a conditional second fork#

pid_t first = fork();

if (first == 0) {
	fork();
}

puts("done");

After the first successful fork, there are two processes: the original parent, where first > 0, and its child, where first == 0. Only the child enters the if and performs the second fork:

There are therefore three processes and three possible done lines, not four. The grandchild inherits the first child's variables, so its copy of first is also zero. The printed order is unspecified because no process waits for another.

Waiting and Exit Status#

A parent can wait for a child to change state:

#include <sys/wait.h>

pid_t waitpid(pid_t pid, int *status, int options);

For the usual case, pass the child's PID and 0 as the options:

int status;
if (waitpid(pid, &status, 0) == -1) {
	perror("waitpid");
	return 1;
}

if (WIFEXITED(status)) {
	printf("exit status: %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
	printf("signal: %d\n", WTERMSIG(status));
}

The integer filled by waitpid() is an encoded status word, not directly the child's exit code. Use macros such as WIFEXITED and WEXITSTATUS.

When a child terminates, a small record remains until its parent collects the status. During this time it is a zombie. The process is no longer executing, but its process-table entry still consumes a resource. A long-running parent must reap its children.

To reap a child simply means collecting this final record with wait() or waitpid(). Think of termination and cleanup as two separate events: the child stops first, then its parent acknowledges the result and lets the kernel discard the remaining bookkeeping.

An orphan is different: it is a still-running process whose original parent terminated.

Practice: Tracing and Calculation#

3. Assuming every call succeeds, how many processes reach puts("done"); after two consecutive unconditional calls to fork()? How many times can done be printed?
4. A child exits with status 7, and waitpid() stores an encoded value in status. Why is status == 7 the wrong test, and what should the parent use?

Practice: Challenge#

5. A parent changes STATUS from old to new after fork(). The child has not called exec() yet. Which value does getenv("STATUS") return in the child, and why?
6. Distinguish a zombie from an orphaned child. Which operation prevents a terminated child from remaining a zombie?

exit() and _exit()#

exit(status) performs normal library cleanup:

• calls functions registered with atexit();
• flushes and closes stdio streams;
• terminates the process and makes the status available to its parent.

_exit(status) terminates immediately without flushing stdio or running those handlers. A child may use _exit() after an exec() failure to avoid flushing buffers copied from the parent.

Normal child termination also causes the parent to receive SIGCHLD. Signals are asynchronous notifications; COMP1521 mainly observes this one through waitpid() rather than building complex signal handlers.

if (pid == 0) {
	char *argv[] = {"/bin/date", "--utc", NULL};
	execv(argv[0], argv);
	perror("execv");
	_exit(127);
}

Fork, Exec and Wait Together#

The classic shell-like pattern is:

sequenceDiagram
    participant P as Parent
    participant C as Child
    P->>C: fork()
    Note over P: receives child PID
    Note over C: receives 0
    C->>C: execv(new program)
    P->>P: waitpid(child PID)
    C-->>P: termination status

pid_t pid = fork();
if (pid == -1) {
	perror("fork");
	return 1;
}

if (pid == 0) {
	char *argv[] = {"/bin/date", "--utc", NULL};
	execv(argv[0], argv);
	perror("execv");
	_exit(127);
}

int status;
if (waitpid(pid, &status, 0) == -1) {
	perror("waitpid");
	return 1;
}

Practice: Writing and Debugging#

7. Complete the child-side error rule: after fork(), call execv(...); if it returns, report the error and terminate with which function—exit() or _exit()—and why?
8. Find the bug: char *args[] = {"wc", "-l"}; execvp(args[0], args);. What exact correction is required?

posix_spawn#

posix_spawn() combines process creation with execution through a standard interface:

#include <errno.h>
#include <spawn.h>
#include <stdio.h>
#include <sys/wait.h>

extern char **environ;

pid_t pid;
char *argv[] = {"/bin/date", "--utc", NULL};

int error = posix_spawn(&pid, argv[0], NULL, NULL, argv, environ);
if (error != 0) {
	errno = error;
	perror("posix_spawn");
	return 1;
}

int status;
if (waitpid(pid, &status, 0) == -1) {
	perror("waitpid");
	return 1;
}

Unlike many POSIX functions, posix_spawn() returns an error number directly rather than returning -1 and setting errno. The example assigns it to errno only so perror() can produce a readable message. A successful spawn means the new process was created; it does not mean that the new program has already finished successfully. Waiting and interpreting the encoded status remain separate parent responsibilities.

posix_spawnp() searches PATH. File-action objects can arrange redirection and pipes before the child program begins; see Pipes and File Redirection.

Why system() is Dangerous#

system(command) gives a string to a shell. That is convenient for throwaway code, but any untrusted text embedded in the command can be interpreted as shell syntax.

// Unsafe if filename came from a user:
char command[1024];
snprintf(command, sizeof command, "cat %s", filename);
system(command);

A filename containing spaces, semicolons or command substitutions changes the meaning. Prefer posix_spawn() or fork() plus exec(), where each argument is a separate string and is not reparsed as shell code.

Practice: Cumulative#

9. Write the control-flow skeleton for a parent which creates one child, has the child run /usr/bin/wc -l input.txt, waits for that exact child, and reports whether it exited normally. Include the important error paths and the terminating NULL in argv.

pid_t pid = fork();
if (pid == -1) {
    perror("fork");
    return 1;
}
if (pid == 0) {
    char *argv[] = {"/usr/bin/wc", "-l", "input.txt", NULL};
    execv(argv[0], argv);
    perror("execv");
    _exit(127);
}

int status;
if (waitpid(pid, &status, 0) == -1) {
    perror("waitpid");
    return 1;
}
if (WIFEXITED(status)) {
    printf("wc exited with %d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
    printf("wc was terminated by signal %d\n", WTERMSIG(status));
}

Processes give independent programs separate address spaces. Concurrency and Threads considers the contrasting design: several execution streams inside one process, deliberately sharing memory and descriptors.