1. The process concept (section 3.1, 3.3 and demos)  Process: An entity capable of requesting and using computer resources (memory, CPU cycles, files, etc). Sometimes called a program in execution. NOTE: two processes might be associated with the same program if there are two instances of that program running simultaneously

2. Figure 3.1  Author refers to code as the text section.

3. Process states  Figure 3.2

4. Context switch  Task of switching the CPU from one process to another.  Requires saving the state of the current process  Requires restoring the state of the next process  Pure OS overhead and can be complex  If the OS is running on a processor, user apps are NOT.

5. Process Creation  A process can create other processes The process that does the creating is called a parent. The newly created process is called a child.  A child process can create others and thus become a parent of those processes.  Every process has a unique process ID assigned by the OS.  Log into Linux and enter ps or ps aux or ps ux.  In Windows, enter CTRL-ALT-Delete and examine the task manager

6. fork() command (Linux)  The fork() command creates a new process that is nearly identical to the creating process. Upon return from the fork, both run and execute the same code  Only difference: int pid = fork(); In the parent, pid is the ID of the child In the child, pid is 0. See program demos

7. exec() command  Command must specify an executable file.  The image of that executable replaces the current executable in memory and begins running.  In effect, a new program is running though NO new processes is created with this command.  Usually done ONLY in the child process after a fork() command  There are actually numerous exec commands (see Linux commands handout) but we won’t distinguish them now.

8. wait() command  Usually done in the parent process.  Waits until a child process finishes and can return the child’s exit status.  Figure 3.11 below  See program demos

9. Zombies  A parent process should always wait on a child process.  A zombie (or defunct) process is: A child process that has finished executing Still has an entry in the OS list of processes Is waiting for the parent to read its exit status via the wait command. Effectively, the process is dead, but not completely – thus a zombie After the wait() the child exits the system and is no longer a zombie.

10.  A system can be overrun with zombies if there’s a non-ending parent that creates processes but never waits on them.  This is a problem  NOTE: if the parent finishes the zombies are removed, but some process are ongoing (e.g. server processes that respond to incoming requests)

11.  Race conditions Refers to the issue of multiple activities producing results in different orders each time they are run. See the race.c demo

12. Signals  A process can generate signals  Another process can catch the signal and respond to it.  It’s a little like exceptions except the generation and catching of signals occurs in different processes.

13.  Linux identifies many signals.  [http://www.comptechdoc.org/os/linux/progra mming/linux_pgsignals.html]http://www.comptechdoc.org/os/linux/progra mming/linux_pgsignals.html  Common are: Ctrl-c (signal number 2 or SIGINT) Ctrl-z (signal number 20 or SIGTSTP) Ctrl-\ (signal number 3 or SIGQUIT) exit() (sends SIGCHLD (#17) signal to parent)

14. example  Run a process and, while running, enter CTRL-C  CTRL-C sends a signal to the process.  The process catches it and exits.  You have the effect of killing the process.

15.  Similar you can enter CTRL-z  The process catches it and goes into a temporary sleep state. You can see this with the ps command  You can resume the process by typing fg process_name

16. kill() command  Sends a signal to a specified process.  See handout and demos

17. signal() command  Sets up signal catching abilities.  Identifies a signal and a function  If the process receives the identified signal, it immediately executes the specified function.  When the function is done, the process resumes its activities.

18.  Run sigcatcher.c Enter ctrl-c Enter ctrl-z Enter ctrl-\ The same signal catching function is used for all three and the function’s logic distinguishes how each is handled differently from each other.

19.  Run sigcatcher1.c Shows different signal catching functions for different signals. Shows what the signal() function returns, as a function.

20.  Run sigcatcher2.c Shows how a process can pause and wait for an incoming signal In this case either ctrl-c or ctrl-\

21.  Recompile sigcatcher.c and call it child Compile and run sigsender.c The latter shows how one process can send a signal to another.

22.  Compile child.c (call it child) and parent1.c Child runs and kills itself or exits gracefully Parent waits for each child and displays how it exited and the id of the child that exited. Child processes may finish in a different order than which they started.

23. Waitpid() command  The wait() command will wait for any child process that finishes.  The waitpid() command allows the parent to specify which child to wait for.  It can also determine the status of the child Child is a zombie Child still running Child no longer exists  See Linux command handout and demo programs.

24.  Run parent2.c with the previous child This parent repeatedly checks the status of each child using the waitpid command.