CSC 322

SYSTEMS PROGRAMMING

EXCEPTIONAL CONTROL FLOW (1)PROCESSES

(based on chapter 8.1 to 8.4)

Computer Systems: A Programmer’s Perspective 3rd Edition 1

AGENDA

oExceptional Control Flow

oExceptions
oProcesses
oProcess Control

Computer Systems: A Programmer’s Perspective 3rd Edition 2

EXCEPTIONAL CONTROL FLOW

Computer Systems: A Programmer’s Perspective 3rd Edition 3

CONTROL FLOW

oProcessors do only one thing:

Physical control flow
• From startup to shutdown, a CPU
simply reads and executes <startup>
(interprets) a sequence of inst1
inst2
instructions, one at a time inst3
Time
• This sequence is the CPU’s control …
instn
flow (or flow of control)
<shutdown>
 Control Transfer: transition from
insti to insti+1
 Program Counter (PC) changes

Computer Systems: A Programmer’s Perspective 3rd Edition 4

ALTERING THE CONTROL FLOW

oControl flows for abrupt changes:

React to changes in program state (handled by internal program)
• Jumps and branches
• Call and return

oBut, it is not insufficient for a useful system:

Difficult to react to changes in system state
try{
• Data arrives from a disk or a network adapter
throw ex;
• Instruction divides by zero }catch (DividedbyZero ex){
cout << “Trying to divide with zero”;
• User hits Ctrl-C at the keyboard }

• System timer expires

oSystem needs mechanisms for “exceptional control flow”

Computer Systems: A Programmer’s Perspective 3rd Edition 5
EXCEPTIONAL CONTROL FLOW (ECF)

oExists at all levels of a computer system

• Low level mechanisms
 Exceptions
 Change in control flow in response to a system event
(i.e., change in system state)
 Implemented using combination of hardware and OS software

• Higher level mechanisms

 Process context switch
 Implemented by OS software and hardware timer
 Signals
 Implemented by OS software
 Nonlocal jumps: setjmp() and longjmp()
 Implemented by C runtime library

Computer Systems: A Programmer’s Perspective 3rd Edition 6

EXCEPTIONS

Computer Systems: A Programmer’s Perspective 3rd Edition 7

EXCEPTIONS

oAn exception is a transfer of control to the OS kernel in

response to some event (i.e., change in processor state)
• Kernel is the memory-resident part of the OS
• Examples of events: Divide by 0, arithmetic overflow, page fault, I/O
request completes, typing Ctrl-C
short x = 200000000 * 3;

Application Program Exception Handler

(user code) (Kernel code)

Event I_current Exception

I_next Exception processing
by exception handler
• Return to I_current
• Return to I_next
• Abort

Computer Systems: A Programmer’s Perspective 3rd Edition 8

EXCEPTION TABLES

oEach type of event has a

unique exception number k
ok = index into exception Exception
table numbers Code for
exception handler 0
• a.k.a. interrupt vector 0 Code for
1 exception handler 1
oHandler k is called each 2
Code for
time exception k occurs

…
exception handler 2

...
n-1
Exception Table Code for
exception handler n-1

Computer Systems: A Programmer’s Perspective 3rd Edition 9

ASYNCHRONOUS EXCEPTIONS

oCaused by events external to the processor

• Interrupts
 Indicated by setting the processor’s interrupt pin
 Handler returns to “next” instruction

Computer Systems: A Programmer’s Perspective 3rd Edition 10

EXAMPLES OF INTERRUPTS

oExamples:
• Timer interrupt
 Every few ms, an external timer chip triggers an interrupt
 Used by the kernel to take back control from user programs
• I/O interrupt from external device
 Hitting Ctrl-C at the keyboard
 Arrival of a packet from a network
 Arrival of data from a disk

Computer Systems: A Programmer’s Perspective 3rd Edition 11

SYNCHRONOUS EXCEPTIONS
oCaused by events that occur as a result of executing an
instruction:
• Traps
 Intentional
 Examples: system calls, breakpoint traps, special instructions
 Returns control to “next” instruction

• Faults
• Aborts
Computer Systems: A Programmer’s Perspective 3rd Edition 12
EXAMPLE OF TRAPS: SYSTEM CALLS

oEach x86-64 system call has a unique ID number

oExamples: (see more in Figure 8.10)
Number Name Description
0 read Read file
1 write Write file
2 open Open file
3 close Close file
4 stat Get info about file
57 fork Create process
59 execve Execute a program
60 _exit Terminate process
62 kill Send signal to process

Computer Systems: A Programmer’s Perspective 3rd Edition 13

SYSTEM CALL - OPENING FILE

oUser calls: open(filename, options)

• Calls __open function, which invokes system call instruction syscall
User code Kernel code
• %rax contains syscall number
• Other arguments in %rdi,
Exception %rsi, %rdx, %r10, %r8, %r9
syscall
cmp
Open file
• Return value in %rax
Returns • Negative value is an error
corresponding to negative
errno
00000000000e5d70 <__open>:
...
e5d79: b8 02 00 00 00 mov $0x2,%eax # open is syscall #2
e5d7e: 0f 05 syscall # Return value in %rax
e5d80: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
...
e5dfa: c3 retq
Computer Systems: A Programmer’s Perspective 3rd Edition 14
SYNCHRONOUS EXCEPTIONS
oCaused by events that occur as a result of executing an
instruction:
• Traps
• Faults
 Unintentional but possibly recoverable
 Examples: page faults (recoverable), protection faults (unrecoverable),
floating point exceptions
 Either re-executes faulting (“current”) instruction or aborts

• Aborts
Computer Systems: A Programmer’s Perspective 3rd Edition 15
EXAMPLE OF FAULTS: PAGE FAULT

oUser writes to memory location

• That portion (page) of user’s memory is currently on disk
User code Kernel code int a[1000];
main ()
{
Exception: page fault a[500] = 13;
movl }
Copy page
from disk
Return and to memory
reexecute movl

80483b7: c7 05 10 9d 04 08 0d movl $0xd,0x8049d10

Computer Systems: A Programmer’s Perspective 3rd Edition 16

SYNCHRONOUS EXCEPTIONS
oCaused by events that occur as a result of executing an
instruction:
• Traps
• Faults
• Aborts
 Unintentional and unrecoverable
 Examples: illegal instruction, parity error, machine check
 Aborts current program

Computer Systems: A Programmer’s Perspective 3rd Edition 17

EXAMPLE: INVALID MEMORY REFERENCE

oSends SIGSEGV signal to user process

• User process exits with “segmentation fault”
User code Kernel code int a[1000];
main ()
{
Exception: page fault a[5000] = 13;
movl }

Detect invalid address

Signal process

80483b7: c7 05 60 e3 04 08 0d movl $0xd,0x804e360

Computer Systems: A Programmer’s Perspective 3rd Edition 18

PROCESSES

Computer Systems: A Programmer’s Perspective 3rd Edition 19

PROCESSES

oDefinition: A process is an instance of a running program.

• One of the most profound ideas in computer science
• Not the same as “program” or “processor”
o Process provides each program with two key
abstractions: Memory
• Logical control flow
 Each program seems to have exclusive use of the CPU Stack
 Provided by kernel mechanism called context switching Heap
Data
• Private address space
Code
 Each program seems to have exclusive use of main
memory. CPU
 Provided by kernel mechanism called virtual memory
Registers

Computer Systems: A Programmer’s Perspective 3rd Edition 20

MULTIPROCESSING: THE ILLUSION

oComputer runs many processes simultaneously

• Applications for one or more users
 Web browsers, email clients, editors, …
• Background tasks
 Monitoring network & I/O devices
Memory Memory Memory

Stack Stack Stack

Heap Heap Heap
Data
Code
Data
Code
… Data
Code

CPU CPU CPU

Registers Registers Registers

Computer Systems: A Programmer’s Perspective 3rd Edition 21

MULTIPROCESSING EXAMPLE - MAC

oRunning program “top”

• Identified by
Process ID
(PID)

oIn the example,

• 123 processes
• 5 are active

Computer Systems: A Programmer’s Perspective 3rd Edition 22

MULTIPROCESSING EXAMPLE - WINDOWS

oRunning program “tasklist”

• Identified by
Process ID
(PID)
• No summary
about
processes

Computer Systems: A Programmer’s Perspective 3rd Edition 23

MULTIPROCESSING: THE (TRADITIONAL) REALITY

Memory
Stack Stack Stack Stack
Heap Heap Heap Heap
Data Data … Data Data
Code Code Code Code
Saved Saved Saved Saved
registers registers registers registers

CPU
Registers

oSingle processor executes multiple processes concurrently

• Process executions interleaved (multitasking)
• Address spaces managed by virtual memory system (later in course)
• Register values for nonexecuting processes saved in memory
Computer Systems: A Programmer’s Perspective 3rd Edition 24
MULTIPROCESSING: THE (TRADITIONAL) REALITY

Memory
Stack Stack Stack Stack
Heap Heap Heap Heap
Data Data … Data Data
Code Code Code Code
Saved Saved Saved Saved
registers registers registers registers

CPU
Registers

oSave current registers in memory

Computer Systems: A Programmer’s Perspective 3rd Edition 25

MULTIPROCESSING: THE (TRADITIONAL) REALITY

Memory
Stack Stack Stack Stack
Heap Heap Heap Heap
Data Data … Data Data
Code Code Code Code
Saved Saved Saved Saved
registers registers registers registers

CPU
Registers

oSchedule next process for execution

Computer Systems: A Programmer’s Perspective 3rd Edition 26

MULTIPROCESSING: THE (TRADITIONAL) REALITY

Memory
Stack Stack Stack Stack
Heap Heap Heap Heap
Data Data … Data Data
Code Code Code Code
Saved Saved Saved Saved
registers registers registers registers

CPU
Registers

oLoad saved registers and switch address space

• Context switch

Computer Systems: A Programmer’s Perspective 3rd Edition 27

MULTIPROCESSING: THE (MODERN) REALITY

Memory
Stack Stack Stack Stack
Heap Heap Heap Heap
Data Data … Data Data
Code Code Code Code
Saved Saved Saved Saved
registers registers registers registers

CPU CPU
Registers Registers

o Multicore processors
• Multiple CPUs on single chip
• Share main memory (and some of the caches)
• Each can execute a separate process
 Scheduling of processors onto cores done by kernel
Computer Systems: A Programmer’s Perspective 3rd Edition 28
CONCURRENT PROCESSES

oEach process is a logical control flow.

• Two processes run concurrently (are concurrent) if their flows overlap in
time
• Otherwise, they are sequential
oExample
Process A Process B Process C
• Running on single core
• Concurrent: A & B, A & C Time

• Sequential: B & C

Computer Systems: A Programmer’s Perspective 3rd Edition 29

USER VIEW OF CONCURRENT PROCESSES

oControl flows for concurrent processes are physically disjoint in

time
• However, we could think of concurrent processes as running in parallel
with each other

oIn the example, Process A Process B Process C

• Process A seems running
while Process B is running. Time

• Process A seems running

when Process C starts.

Computer Systems: A Programmer’s Perspective 3rd Edition 30

CONTEXT SWITCHING

oProcesses are managed by a shared chunk of memory-

resident OS code called the kernel
• Important: the kernel is not a separate process, but rather runs as part
of some existing process.
• Control flow passes from one process to another via a context switch
Process A Process B

Read user code

from disk kernel code context switch
Time

Disk user code

interrupt kernel code context switch
Return
from read user code

Computer Systems: A Programmer’s Perspective 3rd Edition 31

PROCESS CONTROL

Computer Systems: A Programmer’s Perspective 3rd Edition 32

SYSTEM CALL ERROR HANDLING

oOn error, Linux system-level functions typically return -1 and

set global variable errno to indicate cause.
oHard and fast rule:
• You must check the return status of every system-level function
• Only exception is the handful of functions that return void
oExample:
if ((pid = fork()) < 0)
{
fprintf(stderr, "fork error: %s\n", strerror(errno));
exit(0);
}

Computer Systems: A Programmer’s Perspective 3rd Edition 33

ERROR-REPORTING FUNCTIONS

oCan simplify somewhat using an error-reporting function:

void unix_error(char *msg) /* Unix-style error */
{
fprintf(stderr, "%s: %s\n", msg, strerror(errno));
exit(0);
}

if ((pid = fork()) < 0)

unix_error("fork error");

Computer Systems: A Programmer’s Perspective 3rd Edition 34

ERROR-HANDLING WRAPPERS

oWe simplify the code we present to you even further by using

Stevens-style error-handling wrappers:
pid_t Fork(void)
{
pid_t pid;

if ((pid = fork()) < 0)

unix_error("Fork error");
return pid;
}
• Obtaining Process IDs
pid = Fork();
 pid_t getpid(void)
 Returns PID of current process
 pid_t getppid(void)
 Returns PID of parent process

Computer Systems: A Programmer’s Perspective 3rd Edition 35

STATES OF A PROCESS

oFrom a programmer’s perspective, we can think of a process

as being in one of three states
• Running
 Process is either executing, or waiting to be executed and will
eventually be scheduled (i.e., chosen to execute) by the kernel
• Stopped
 Process execution is suspended and will not be scheduled until further
notice (next lecture when we study signals)
• Terminated
 Process is stopped permanently

oNote that there could be more states

• For instance, waiting, suspended, ready and so on.
Computer Systems: A Programmer’s Perspective 3rd Edition 36
CREATING PROCESSES

oParent process creates a new running child process by calling

fork
int fork(void)
• Returns 0 to the child process, child’s PID to parent process
• Child is almost identical to parent:
 Child get an identical (but separate) copy of the parent’s virtual address
space.
 Child gets identical copies of the parent’s open file descriptors
 Child has a different PID than the parent

oNote that fork is called once but returns twice.

Computer Systems: A Programmer’s Perspective 3rd Edition 37

TREE OF PROCESSES IN LINUX
init
pid = 1

login kthreadd sshd

pid = 8415 pid = 2 pid = 3028

bash khelper pdflush sshd

pid = 8416 pid = 6 pid = 200 pid = 3610

emacs tcsch
ps
pid = 9204 pid = 4005
pid = 9298

Computer Systems: A Programmer’s Perspective 3rd Edition 38

TERMINATING A PROCESS

oProcess mainly becomes terminated for one of three reasons:

• Receiving a signal whose default action is to terminate (next lecture)
• Returning from the main routine
• Calling the exit function
void exit(int status)
 Terminates with an exit status of status
 Convention: normal return status is 0, nonzero on error
 Another way to explicitly set the exit status is to return an integer value
from the main routine

oexit is called once but never returns.

Computer Systems: A Programmer’s Perspective 3rd Edition 39

EXAMPLE: fork
int main()
{ oCall once, return twice
pid_t pid;
int x = 1; oConcurrent execution
pid = Fork(); • Can’t predict execution order of
if (pid == 0) /* Child */
{ parent and child
printf("child : x=%d\n", ++x);
exit(0); oDuplicate but separate address
}
space
/* Parent */
printf("parent: x=%d\n", --x); • x has a value of 1 when fork
exit(0); returns in parent and child
}
• Subsequent changes to x are
linux> ./fork independent
parent: x=0
child : x=2 oShared open files
• stdout is the same in both
parent and child
Computer Systems: A Programmer’s Perspective 3rd Edition 40
MODELING FORK WITH PROCESS GRAPHS

oA process graph is a useful tool for capturing the partial

ordering of statements in a concurrent program:
• Each vertex is the execution of a statement
• a → b means a happens before b
• Edges can be labeled with current value of variables
• printf vertices can be labeled with output
• Each graph begins with a vertex with no inedges
oAny topological sort of the graph corresponds to a feasible
total ordering.
• Total ordering of vertices where all edges point from left to right

Computer Systems: A Programmer’s Perspective 3rd Edition 41

PROCESS GRAPH
int main() Child(pid == 0)
{ Child
pid_t pid; printf exit x=2
int x = 1; Process
x=1
Parent
main fork printf exit
pid = Fork(); x=0
Parent(pid != 0)
if (pid == 0) /* Child */
{
printf("child : x=%d\n", ++x);
exit(0); • Which processes have
} the same PID?
/* Parent */
printf("parent: x=%d\n", --x);
exit(0);
}

Computer Systems: A Programmer’s Perspective 3rd Edition 42

FEASIBLE ORDERS OF PROCESSING

oSimple labeled graph

Child
e f

a b c d
Parent

• Feasible ordering:
a b e c f d
 Ordering depends on the
system and the current situation.

(feasible) a b e f c d

(infeasible) a b c f e d

Computer Systems: A Programmer’s Perspective 3rd Edition 43

TWO CONSECUTIVE FORKs
Bye
void fork2() printf
{ Bye
L1
printf("L0\n");
fork(); printf fork printf
printf("L1\n"); Bye
fork(); printf
printf("Bye\n");
} L0 L1 Bye
printf fork printf fork printf

Linux> ./fork2 Linux> ./fork2

L0 L0
L1 Bye
Bye L1
Bye Bye
L1 L1
Bye Bye
Bye feasible! Bye infeasible!
Computer Systems: A Programmer’s Perspective 3rd Edition 44
NESTED FORKs IN PARENT

void fork4()
{
printf("L0\n"); Bye Bye
if (fork() != 0) printf printf
{ L0 L1 L2 Bye
printf("L1\n"); printf fork printf printf
printf fork
if (fork() != 0)
{
printf("L2\n");
}
}
printf("Bye\n"); Linux> ./fork4 Linux> ./fork4
} L0 L0
L1 Bye
Bye L1
Bye Bye
L2 Bye
Bye feasible! L2 infeasible!

Computer Systems: A Programmer’s Perspective 3rd Edition 45

NESTED FORKs IN CHILDREN
L2 Bye
void fork5()
{ printf printf
printf("L0\n"); L1 Bye
if (fork() == 0) printf fork printf
{ L0 Bye
printf("L1\n"); printf
printf fork
if (fork() == 0)
{
printf("L2\n");
}
}
printf("Bye\n"); Linux> ./fork5 Linux> ./fork5
} L0 L0
Bye Bye
L1 L1
• Can you find the L2 Bye
total ordering in a Bye Bye
Bye feasible! L2 infeasible!
given output?

Computer Systems: A Programmer’s Perspective 3rd Edition 46

REAPING CHILD PROCESSES
o Idea
• When process terminates, it still consumes system resources
 Examples: Exit status, various OS tables
• Called a “zombie”
 Living corpse, half alive and half dead

o Reaping
• Performed by parent on terminated child (using wait or waitpid)
• Parent is given exit status information
• Kernel then deletes zombie child process
o What if parent doesn’t reap?
• If any parent terminates without reaping a child, then the orphaned child
will be reaped by init process (pid == 1)
• So, only need explicit reaping in long-running processes
 e.g., shells and servers
Computer Systems: A Programmer’s Perspective 3rd Edition 47
EXAMPLE ZOMBIE PROCESS
void fork7() {
if (fork() == 0) {
/* Child */
printf("Terminating Child, PID = %d\n", getpid());
exit(0);
} else {
printf("Running Parent, PID = %d\n", getpid());
while (1)
; /* Infinite loop */
}
}

Computer Systems: A Programmer’s Perspective 3rd Edition 48

EXAMPLE: ZOMBIE (CHILD) PROCESS
void fork7() {
if (fork() == 0) {
/* Child */
printf("Terminating Child, PID = %d\n", getpid());
exit(0);
} else {
printf("Running Parent, PID = %d\n", getpid());
linux> ./forks 7 & while (1)
[1] 6639 ; /* Infinite loop */
}
Running Parent, PID = 6639
}
Terminating Child, PID = 6640
linux> ps
PID TTY TIME CMD
6585 ttyp9 00:00:00 tcsh
6639 ttyp9 00:00:03 forks
o ps shows child process as
6640 ttyp9 00:00:00 forks <defunct> “defunct” (i.e., a zombie)
6641 ttyp9 00:00:00 ps
linux> kill 6639 o To kill the child process, kill
[1] Terminated
parent
linux> ps
PID TTY TIME CMD • Killing parent allows child to be
6585 ttyp9 00:00:00 tcsh
reaped by init
6642 ttyp9 00:00:00 ps
Computer Systems: A Programmer’s Perspective 3rd Edition 49
EXAMPLE: NON-TERMINATING CHILD
void fork8()
{
if (fork() == 0) {
/* Child */
printf("Running Child, PID = %d\n",
getpid());
while (1)
; /* Infinite loop */
} else {
printf("Terminating Parent, PID = %d\n",
getpid());
linux> ./forks 8 exit(0);
Terminating Parent, PID = 6675 }
Running Child, PID = 6676 }
linux> ps
PID TTY TIME CMD
6585 ttyp9
6676 ttyp9
00:00:00 tcsh
00:00:06 forks
o Child process still active even
6677 ttyp9 00:00:00 ps though parent has terminated
linux> kill 6676
linux> ps o Must kill child explicitly, or else
PID TTY TIME CMD will keep running indefinitely
6585 ttyp9 00:00:00 tcsh
6678 ttyp9 00:00:00 ps
Computer Systems: A Programmer’s Perspective 3rd Edition 50
SYNCHRONIZING WITH CHILDREN

oParent reaps a child by calling the wait function

int wait(int *child_status)
• Suspends current process until one of its children terminates
• Return value is the pid of the child process that terminated
• If child_status != NULL, then the integer it points to will be set
to a value that indicates reason the child terminated and the exit
status:
 Checked using macros defined in wait.h
 WIFEXITED, WEXITSTATUS, WIFSIGNALED, WTERMSIG,
WIFSTOPPED, WSTOPSIG, WIFCONTINUED
 See textbook for details

Computer Systems: A Programmer’s Perspective 3rd Edition 51

EXAMPLE: SYNCHRONIZING WITH CHILD

void fork9() { Child(pid == 0)

int child_status; HC exit
printf
if (fork() == 0) {
printf("HC: hello from child\n");
CT
exit(0);
HP Bye
} else {
printf("HP: hello from parent\n"); fork printf wait printf
wait(&child_status); Parent(pid != 0)
printf("CT: child has terminated\n");
}
printf("Bye\n");
}

linux> ./fork9 linux> /.fork9

HC HP
HP CT
CT Bye
Bye HC
feasible! infeasible!
Computer Systems: A Programmer’s Perspective 3rd Edition 52
EXAMPLE: SYNCHRONIZING WITH CHILDREN

oIf multiple children completed, will take in arbitrary order

• Can use macros WIFEXITED and WEXITSTATUS to get information about
exit status
void fork10() {
pid_t pid[N];
int i, child_status;

for (i = 0; i < N; i++)

if ((pid[i] = fork()) == 0) {
exit(100+i); /* Child */
}
for (i = 0; i < N; i++) { /* Parent */
pid_t wpid = wait(&child_status);
if (WIFEXITED(child_status))
printf("Child %d terminated with exit status %d\n",
wpid, WEXITSTATUS(child_status));
else
printf("Child %d terminate abnormally\n", wpid);
}
} Computer Systems: A Programmer’s Perspective 3rd Edition 53
EXAMPLE: WAITING FOR A SPECIFIC PROCESS

pid_t waitpid(pid_t pid, int &status, int options)

• Suspends current process until specific process terminates
 Various options: see textbook
void fork11() {
pid_t pid[N];
int i;
int child_status;

for (i = 0; i < N; i++)

if ((pid[i] = fork()) == 0)
exit(100+i); /* Child */
for (i = N-1; i >= 0; i--) {
pid_t wpid = waitpid(pid[i], &child_status, 0);
if (WIFEXITED(child_status))
printf("Child %d terminated with exit status %d\n",
wpid, WEXITSTATUS(child_status));
else
printf("Child %d terminate abnormally\n", wpid);
}
} Computer Systems: A Programmer’s Perspective 3rd Edition 54
LOADING AND RUNNING PROGRAMS

o Loads and runs in the current process:

• Executable file filename
 Can be object file or script file beginning with #!interpreter
(e.g., #!/bin/bash)
• …with argument list argv
 By convention argv[0]==filename
• …and environment variable list envp
 “name=value” strings (e.g., USER=droh)
 getenv, putenv, printenv
int execve(char *filename, char *argv[], char *envp[])
 Overwrites code, data, and stack
 Retains PID, open files and signal context
 Called once and never returns
 …except if there is an error

Computer Systems: A Programmer’s Perspective 3rd Edition 55

INITIAL STATUS OF STRUCTURE OF THE STACK
Null-terminated Bottom of stack
environment variable strings
oThe stack is organized, Null-terminated
when a new program command-line arg strings

starts,
envp[n] == NULL
envp[n-1] environ
... (global var)
envp[0]
argv[argc] = NULL envp
argv[argc-1] (in %rdx)
...
argv argv[0]
(in %rsi)

argc Stack frame for

(in %rdi) libc_start_main
Top of stack
Future stack frame for
main
Computer Systems: A Programmer’s Perspective 3rd Edition 56
EXAMPLE: EXECVE

oExecutes “/bin/ls –lt /usr/include” in child

process using current environment:
if ((pid = Fork()) == 0) { /* Child runs program */
if (execve(myargv[0], myargv, environ) < 0) {
printf("%s: Command not found.\n", myargv[0]);
exit(1);
}
}

myargv[argc] = NULL
(argc == 3) myargv[2] “/usr/include”
myargv[1] “-lt”
myargv myargv[0] “/bin/ls”
envp[n] = NULL
envp[n-1] “PWD=/usr/droh”
…
envp[0] “USER=droh”
environ
Computer Systems: A Programmer’s Perspective 3rd Edition 57
SUMMARY

oExceptions
• Events that require nonstandard control flow
• Generated externally (interrupts) or internally (traps and faults)
oProcesses
• At any given time, system has multiple active processes
• Only one can execute at a time on a single core, though
• Each process appears to have total control of
processor + private memory space

Computer Systems: A Programmer’s Perspective 3rd Edition 58

SUMMARY – CONT’D

oSpawning processes
• Call fork
• One call, two returns
oProcess completion
• Call exit
• One call, no return
oReaping and waiting for processes
• Call wait or waitpid
oLoading and running programs
• Call execve (or variant)
• One call, (normally) no return
Computer Systems: A Programmer’s Perspective 3rd Edition 59