University
of
Washington
Sec3on
8:
Processes
¢ What
is
a
process
¢ Crea3ng
processes
¢ Fork-‐Exec
Fork-‐Exec
University
of
Washington
Fork-‐Exec
¢ fork-‐exec
model:
§ fork()
creates
a
copy
of
the
current
process
§ execve()
replaces
the
current
process’
code
&
address
space
with
the
code
for
a
different
program
§ There
is
a
whole
family
of
exec
calls
–
see
exec(3)
and
execve(2)
// Example arguments: path="/usr/bin/ls”,
// argv[0]="/usr/bin/ls”, argv[1]="-ahl", argv[2]=NULL
void fork_exec(char *path, char *argv[])
{
pid_t pid = fork();
if (pid != 0) {
printf("Parent: created a child %d\n”, pid);
} else {
printf("Child: exec-ing new program now\n");
execv(path, argv);
}
printf("This line printed by parent only!\n");
}
Fork-‐Exec
University
of
Washington
Exec-‐ing
a
new
program
Stack
Very
high-‐level
diagram
of
what
happens
when
you
run
the
Heap
command
”ls”
in
a
Linux
shell:
Data
Code:
/usr/bin/bash
fork():
parent
child
child
Stack
Stack
Stack
exec():
Heap
Heap
Data
Data
Data
Code:
/usr/bin/bash Code:
/usr/bin/bash Code:
/usr/bin/ls
Fork-‐Exec
University
of
Washington
execve:
Loading
and
Running
Programs
Stack
bo/om
Null-‐terminated
¢ int execve( env
var
strings
char *filename, Null-‐terminated
char *argv[], cmd
line
arg
strings
char *envp[] unused
)
envp[n]
==
NULL
¢ Loads
and
runs
in
current
process:
envp[n-‐1]
§ Executable
filename …
envp[0]
§ With
argument
list
argv
argv[argc]
==
NULL
§ And
environment
variable
list
envp argv[argc-‐1]
§ Env.
vars:
“name=value”
strings
…
(e.g.
“PWD=/homes/iws/pjh”)
argv[0]
¢ execve
does
not
return
(unless
error)
Linker
vars
envp
¢ Overwrites
code,
data,
and
stack
argv
§ Keeps
pid,
open
files,
a
few
other
items
argc
Stack
frame
for
Fork-‐Exec
main Stack
top
University
of
Washington
exit:
Ending
a
process
¢ void exit(int status)
§ Exits
a
process
Status
code:
0
is
used
for
a
normal
exit,
nonzero
for
abnormal
exit
§
§ atexit()
registers
funcXons
to
be
executed
upon
exit
void cleanup(void) {
printf("cleaning up\n");
}
void fork6() {
atexit(cleanup);
fork();
exit(0);
}
Fork-‐Exec
University
of
Washington
Zombies
¢ Idea
§ When
process
terminates,
it
sXll
consumes
system
resources
Various
tables
maintained
by
OS
§
§ Called
a
“zombie”
§ A
living
corpse,
half
alive
and
half
dead
¢ Reaping
§ Performed
by
parent
on
terminated
child
§ Parent
is
given
exit
status
informaXon
§ Kernel
discards
process
¢ What
if
parent
doesn’t
reap?
§ If
any
parent
terminates
without
reaping
a
child,
then
child
will
be
reaped
by
init
process
(pid
==
1)
§ But
in
long-‐running
processes
we
need
explicit
reaping
§ e.g.,
shells
and
servers
Fork-‐Exec
University
of
Washington
wait:
Synchronizing
with
Children
¢ int wait(int *child_status)
§ Suspends
current
process
(i.e.
the
parent)
unXl
one
of
its
children
terminates
§ Return
value
is
the
pid
of
the
child
process
that
terminated
§ On
successful
return,
the
child
process
is
reaped
§ If
child_status
!= NULL,
then
the
int
that
it
points
to
will
be
set
to
a
status
indicaXng
why
the
child
process
terminated
§ There
are
special
macros
for
interpreXng
this
status
–
see
wait(2)
¢ If
parent
process
has
mulXple
children,
wait()
will
return
when
any
of
the
children
terminates
§ waitpid()
can
be
used
to
wait
on
a
specific
child
process
Fork-‐Exec
University
of
Washington
wait
Example
void fork_wait() {
int child_status;
pid_t child_pid;
if (fork() == 0) {
HC Bye
printf("HC: hello from child\n");
} else {
child_pid = wait(&child_status); CT Bye
printf("CT: child %d has terminated\n”,
child_pid);
}
printf("Bye\n");
exit(0);
}
Fork-‐Exec
University
of
Washington
Process
management
summary
¢ fork
gets
us
two
copies
of
the
same
process
(but
fork()
returns
different
values
to
the
two
processes)
¢ execve
has
a
new
process
subs3tute
itself
for
the
one
that
called
it
§ Two-‐process
program:
First
fork()
§
§ if
(pid
==
0)
{
//child
code
}
else
{
//parent
code
}
§ Two
different
programs:
§ First
fork()
§ if
(pid
==
0)
{
execve()
}
else
{
//parent
code
}
§ Now
running
two
completely
different
programs
¢ wait
/
waitpid
used
to
synchronize
parent/child
execu3on
and
to
reap
child
process
Fork-‐Exec
University
of
Washington
Summary
¢ Processes
§ At
any
given
Xme,
system
has
mulXple
acXve
processes
§ Only
one
can
execute
at
a
Xme,
but
each
process
appears
to
have
total
control
of
the
processor
§ OS
periodically
“context
switches”
between
acXve
processes
§ Implemented
using
excep,onal
control
flow
¢ Process
management
§ fork-‐exec
model
Fork-‐Exec
