copy files from /home/hwang/cs375/lecture14 project 4...

Thursday, October 15 CS 375 UNIX System Programming - Lecture 14 1

Lecture 14

● Copy files from /home/hwang/cs375/lecture14● Project 4 posted to course webpage.● Questions?


Outline

● Introduction to processes● Creating new processes● Avoiding zombie processes

● Note: this material is covered in both BLP and APUE (as indicated in the syllabus) as well as the man pages for the various system calls.


Introduction

● Suppose we are writing an application that requires the production of a nice graph, or the conversion an image from GIF to PNG formats, etc.

● We could do one of the following to solve this problem: ● write the required routines from scratch● find and use library routines that do the work● use existing programs such as gnuplot or the PNM

utilities.


Introduction

● The third approach can be very powerful. It is often the easiest method as well. Why not use an existing utility that does what is needed and is known to be efficient and robust?

● UNIX allows us run other programs from our program and communicate with these programs using a number of different interprocess communication (IPC) methods.


Introduction

● UNIX allows us to do this in a manner that is completely transparent to the user of our program. That is, we can use gnuplot to produce our graphs, but the user does not necessarily need to know that.

● In BLP Chapter 11 and APUE Chapter 8, we learn to run other programs from our program. In BLP Chapters 13-15 and APUE Chapters 15, we will learn how to communicate (pass data) with these other programs.


What is a Process?

● A program is a collection of instructions and data kept in an file.

● A process is a running program. It consists of segments containing instructions, user data, and system data.

● The instruction and user data segments are initialized from the program.

● System data includes the current directory, open file descriptors, total CPU time, etc.


Parent and Child Processes

● A new child process is created by the kernel on behalf of a parent process (via fork()).

● A child inherits most of the system data from the parent. For example, files that are opened by the parent, also will be opened in the child.

● Each process has a unique process ID (PID - a positive int). getpid( ) and getppid( ) can be used to find the current and parent process IDs. The init process has PID 1.


Process Groups

● Each process is a member of a unique process group with its own process group ID (PGID). When a process is created it is a member of its parent's process group.

● One process is the process group leader. The PGID is the same as the leader PID.

● Only one process group is the foreground process group. The terminal device driver sends tty signals (interrupt, quit, etc) to each process in the foreground process group.


Additional Process Information

● At the command line use “ps ajx” to list the PIDs, PPIDs and PGIDs of all processes.

● A parent may wait for a child to terminate by using the wait( ) or waitpid( ) routines.

● If a child ends before the parent calls wait( ), then the child lives on as a “zombie” process until the parent calls wait( ) or ends.

● If a parent ends, a child's parent process ID is set to 1. (i.e., the child is adopted by init, which immediately issues a wait.)


Process Creation: system( )

● The system( ) function (defined in <cstdlib>) can be used to run another program (and thereby create a new process) from an existing process:system("program_name");

● The parent process waits until the program completes. (See sys_xmpl.cpp)

● The program is run just as if the following had been entered at the command prompt:$ bash c program_name


Process Creation: fork( )/exec( )

● The system( ) function is built upon the fork( ), exec( ) (both defined in <unistd.h>) and wait( ) (defined in <sys/wait.h>) routines.

● fork( ) creates a child process that is a clone of the parent (identical instruction, user-data, and system-data segments).

● The exec( ) routine reinitializes a process from a designated program (file on disk).

● fork( ) and exec( ) are usually used together.


The exec( ) System Calls

● There are six exec( ) calls. First execl( ) - arguments are a vararg list ending with 0.int execl(char *path, char *arg0, ..., char *argn, (char *)0);

● Here is an example:execl(“/bin/ls”, “ls”, “al”, “/tmp”, (char *)0);

● Recall that a new process is not created by exec( ). The code and user-data segments are reinitialized from the indicated program. The system data segment is not overwritten.


The exec( ) System Calls

● exec( ) is the only way to execute a program under UNIX. (See exc_xmpl.cpp)

● Other exec( ) calls are execlp( ), execle( ), execv( ), execvp( ) and execve( ):● execv*( ) routines expect the arguments to be

passed in an array (i.e. char *argv[ ]).● exec*p( ) routines look for the program in the PATH

(vs. in the environment's PATH).● exec*e( ) routines pass a pointer to a new

environment array (instead of a copy).


The fork( ) System Call

● If we only had exec( ) there would be only one process running on the system. We could run different programs by having each program call exec( ) to start a new program.

● The fork( ) system call is the only way to create a new process. The new (child) process's instruction, user-data, and system-data segments are almost exact copies of the old (parent) process segments. (The PIDs and PPIDs will, of course, be different.)



● The child gets copies of the parent's open file descriptors. The file pointer is in the system file table and is shared by both processes.

● When fork( ) returns, both processes (parent and child) get different return values (of type pid_t defined in <sys/types.h>). The child gets 0 while the parent gets the PID of the child. Usually the child will do an exec( ), while the parent either waits for the child or goes off to do something else.



● For example, the following code:cout << “Start of test” << endl;pid = fork();cout << “fork() returned ” << pid << endl;

● might display (exact order depends on which process executes first):Start of testfork() returned 0fork() returned 17625

● See frk_xmpl1.cpp



● Examine frk_xmpl2.cpp● How many processes will be created? Can

output with count=3 appear before output with count=1?

● See vssh_xmpl.cpp for a very simple shell program.


The wait( ) System Call

● wait( ) causes the parent to sleep until any child terminates:int status;switch (fork()) { case 0: // the child execvp(program, args); default: // the parent pid = wait(&status);}

● It is not necessary for a parent to wait.● See wait_xmpl.cpp for example code.


Using wait( )

● wait( ) returns the child's PID and passes back the child's exit status in the status argument. The exit status is encoded and can be decoded using macros in <sys/wait.h>:WIFEXITED(status) Non-zero if normal terminationWEXITSTATUS(status) Exit status (normal termination)WIFSIGNALED(status) Non-zero if signal terminationWTERMSIG(status) Signal number (if signal term)WIFSTOPPED(status) Non-zero if stopped

● A stopped process is different than a terminated one (it can be restarted).


Using waitpid( )

● waitpid( ) allows you to: (1) wait on a specific process, (2) check status without blocking, and (3) supports job control.pid_t waitpid(pid_t pid, int *status, int opts)

If pid == -1, waitpid( ) waits for any child.If pid > 0, waitpid( ) waits for child with that pid. status is defined just as for wait( ). If opts is WNOHANG, check status and return.


Zombie Processes

● Recall that a parent process creates a child process and that the parent process can wait for the child to end, receiving the child's termination status (normal or signal) and exit value via the wait( ) system call.

● In order for the child to terminate completely, its status information must be received by a wait( ) call. Until this happens, the child process hangs around, not executing anything, but not dead either (hence calling them zombies).


Zombie Processes

● See zmb_xmpl1.cpp and zmb_xmpl2.cpp● It is not good for a system to accumulate

zombie processes. They take up resources and do not produce any results.

● This is particularly bad if the parent process is a server daemon that is not expected to exit in the normal case.


Avoiding Zombies

● If we want to "disown" a child process we can call fork twice (aka double fork):if ( (pid = fork()) == 0) { // child process if ( (pid = fork()) == 0) { // "grandchild" process // parent becomes init when child exits execvp(program, args); } // child process, so exit // "grandchild" is adopted by init exit(0);}waitpid(pid, NULL, 0); // wait for child process// we're the parent – go on and do our own thing// we don't have to worry about the "grandchild"

copy files from /home/hwang/cs375/lecture14 project 4...

Documents