The process concept (section 3.1, 3.3 and demos)

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: • intpid = 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/programming/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 fgprocess_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.