CPS 356 & 444/544 Lecture notes: Processes


Coverage: [UPE] §7.4 (pp. 220-225), and [USP] Chapters 1, 2 (pp. 31-38), & 3 and §4.6 (pp. 119-128)

fork exercises

  • open followed by fork; consequences?
  • fork followed by open; consequences?
  • what about the consequences of buffering? printf followed by a fork, with and without a newline
  • creating a chain of n processes
  • creating a fan of n processes


  • causes the parent (caller) to block until child's status becomes available (typically after it terminates, but also when process stopped) or until the caller receives a signal
  • wait vs. waitpid (can wait for a specific process and be used to poll a process for its status without blocking)
  • r_wait
  • how can a process wait for all of its children?
  • self-study: functions (macros) for testing the return status of a child (see [USP] §3.4.1, pp. 76-77)
  • zombie process, orphans, init process

Graphical depiction of wait

(ref. [ATT] 6-41)

fork and wait exercises

  • [USP] exercise 3.10, p. 69
  • [USP] exercise 3.18, p. 74
  • [USP] exercise 3.20, p. 75
  • [USP] exercise 3.21, p. 76


  • family of functions which provide support for swapping out the image of the calling process and replacing it with a new image
  • traditional fork-exec sequences
    • child swaps in the new image (with exec)
    • parents continues to execute original code
  • 6 variations differ in the way command-line arguments and the environment are passed, and in relative and absolute paths to executable
    • use execl (execl, execlp, execle) functions when you know the number of command-line arguments at compile time
    • use execv (execv, execvp, execve) functions when you will not know the number of command-line arguments until run time; use an argument array to pass command-line arguments (e.g., such as one produced with makeargv); how can the combined use of exec and makeargv cause a memory leak?
    • trick to remember which call does what
  • exec ksh (shell builtin)
  • system function: invokes a command-line in the parent shell

Graphical depiction of exec

(ref. [ATT] 6-21)

Graphical depiction of suite of exec system calls

Investigating questions

(courtesy William Kimball, CPS 445, Winter 2006)
  • why go through the overhead of copying process image if you are simply going to replace it with another image?
    • newer versions of fork (see 3.0BSD) do not copy the process image on a fork until a modification to address space is made; this is called a copy-on-write
    • does system address this?
      • investigate vfork
        • same as fork but suspends the parent until an exec or exit is called
        • does not copy the process image, shares it instead
      • system calls vfork and exec then waitpid, blocks until child terminates
  • can the l family of exec calls be used when the number of arguments are unknown until run-time? build a string representing the call to execlp and then invoke it
    • trivial in an interpreted, functional language such as Scheme
    • how about in C?

Overview of process creation and manipulation system calls

(ref. [ATT] 6-7)


prototyped in string.h

char* strtok (char* restrict s1, const char* restrict delimiter);
  • first and subsequent calls are different
  • tokenizes string in place (i.e., does not allocate new space for tokens)
  • graphical depiction of string before and after call to strtok


    (regenerated with minor modifications from [USP] Fig. 2.3, p. 36)


    (regenerated with minor modifications from [USP] Fig. 2.4, p. 36)

Reusing argv

Making an argv

must convert

(regenerated with minor modifications from [USP] Fig. 2.4, p. 36)


([USP] Fig. 2.4, p. 36)


  • ref. [USP] §2.6 (pp. 31-38)
  • three versions
    • char** makeargv (char* s);
    • int makeargv (char* s, char*** argvp);
    • int makeargv (const char* s, const char* delimiters, char*** argvp);
  • for instance, ./a.out -c tom and -m jerry
  • importance of cleaning up after yourself; [USP] example 2.19 on p. 38 (freemakeargv.c)
  • [USP] exercise 2.24 on p. 51 (getpaths.c)
  • converts

    (regenerated with minor modifications from [USP] Fig. 2.4, p. 36)


    ([USP] Fig. 2.4, p. 36)

Process recap

  • fork
    • called once, returns twice
    • initial value of
      • child's data is parent's data at time of fork
      • child's PC is instruction immediately following fork
    • child and parent have same
      • user id
      • group id
      • process group id
      • root directory
      • current working directory
      • signal handling settings
      • file mode creation mask
    • they differ in
      • process id
      • parent process id
    • child and parent share
      • data
      • open files
        • typically parent closes file after fork to avoid sharing file
        • though can be used as a communication mechanism
      • do parent and child share program text in main memory?
    • they do not share file descriptors; child has its own copies of parent's file descriptors
    • when is it convenient to have exact copies of parent process in memory? consider a network server process; might fork itself to handle a request
    • how is fork executed?
  • how is execlp executed?
  • UNIX init, login, and command shell processes
  • background processes
    • call setsid to prevent the process from receiving any signals as a result of a ctrl-c from a controlling terminal
    • interesting questions
      • (courtesy Matt Mize, CPS 445, Winter 2006) since parent does not wait for a background process, does the init process wait for it?
      • (courtesy Matt Mize, CPS 445, Winter 2006) does running a process in the background change the parent pid of the background process?
      • can we pass an & to the execl family of functions to run the swapped-in process in the background?

Cooperating processes

  • various processes share data
  • cooperating processes must communicate and synchronize activities
  • one classic example: consumer-producer problem
  • there are relationships between processes

Concurrency and communication

  • go hand in hand with each other
  • concurrent: one or more events which occur either simultaneously (at the same time) or so close together in time that they seems to occur at the same time; later part conflicts with the dictionary definition of concurrency (i.e., simultaneous, concomitant, and at the same time)
  • two ways to achieve concurrency in a computer system:
    • use multiple physical processors (called a multiprocessor system)
    • time-share a single CPU among multiple process (i.e., interleave the executions of the instructions of each process by allocation a very small fraction of time to each process (called the time slice) and context switching between processes when the slice expires)
  • concurrency is achieved in UNIX with the system calls fork, wait, and exec
  • processes with a common ancestor can communicate through pipes
  • processes without common ancestor can communicate through signals, queues, semaphores, monitors, shared address space, messages

Distributed computation

  • client-server model (e.g., ftp and http)
  • object-based model
    • theme: objects passing messages to each other
    • encourages code reuse
  • application (software) layers (e.g.,
    • MPI (Message Passing Interface)
    • CORBA (Common Object Request Broker Architecture)
    • RMI (Remote Method Invocation) and
    • other P2P (Peer to Peer) approaches)


    [ATT] UNIX System Calls and Libraries -- Part 1, Version 2.1.1, AT&T, 1990.
    [C] C Language for Experienced Programmers, Version 2.0.0, AT&T, 1988.
    [UPE] B.W. Kernighan and R. Pike. The UNIX Programming Environment. Prentice Hall, Upper Saddle River, NJ, Second edition, 1984.
    [USP] K.A. Robbins and S. Robbins. UNIX Systems Programming: Concurrency, Communication, and Threads. Prentice Hall, Upper Saddle River, NJ, Second edition, 2003

Return Home