Chapter 8. Process Handling
The Unix operating system built its reputation on a small number of concepts, all of which are simple yet powerful. We've seen most of them by now: standard input/output, pipes, text-filtering utilities, the tree-structured filesystem, and so on. Unix also gained notoriety as the first small-computer operating system to give each user control over more than one process. We call this capability user-controlled multitasking.
If Unix is the only operating system that you're familiar with, you might be surprised to learn that several other major operating systems have been sadly lacking in this area. For example, Microsoft's MS-DOS, for IBM PC compatibles, has no multitasking at all, let alone user-controlled multitasking. IBM's own VM/CMS system for large mainframes handles multiple users but gives them only one process each. Compaq's OpenVMS has user-controlled multitasking, but it is limited and difficult to use. The latest generation of small-computer operating systems, such as Apple's Macintosh OS X (which is BSD-based) and Microsoft's Windows (Windows 95 and later), finally include user-controlled multitasking at the operating system level.
But if you've gotten this far in this book, you probably don't think that multitasking is a big deal. You're probably used to the idea of running a process in the background by putting an ampersand (&) at the end of the command line. You have also seen the idea of a shell subprocess in Chapter 4, when we showed how shell scripts run.
In this chapter, we cover most of the Korn shell's features that relate to multitasking and process handling in general. We say "most" because some of these features are, like the file descriptors we saw in Chapter 7, of interest only to low-level systems programmers.
We start out by looking at certain important primitives for identifying processes and for controlling them during login sessions and within shell scripts. Then we move out to a higher-level perspective, looking at ways to get processes to communicate with each other. The Korn shell's coroutine facility is the most sophisticated interprocess communication scheme that we'll examine; we also look in more detail at concepts we've already seen, like pipes and shell subprocesses.
Don't worry about getting bogged down in low-level technical details about Unix. We provide only the technical information that is necessary to explain higher-level features, plus a few other tidbits designed to pique your curiosity. If you are interested in finding out more about these areas, refer to your Unix Programmer's Manual or a book on Unix internals that pertains to your version of Unix.
We strongly recommend that you try out the examples in this chapter. The behavior of code that involves multiple processes is not as easy to understand on paper as most of the other examples in this book.
Unix gives all processes numbers, called process IDs, when they are created. You will notice that, when you run a command in the background by appending & to it, the shell responds with a line that looks like this:
$ fred &  2349
In this example, 2349 is the process ID for the fred process. The  is a job number assigned by the shell (not the operating system). What's the difference? Job numbers refer to background processes that are currently running under your shell, while process IDs refer to all processes currently running on the entire system, for all users. The term job basically refers to a command line that was invoked from your login shell.
If you start up additional background jobs while the first one is still running, the shell numbers them 2, 3, etc. For example:
$ bob &  2367 $ dave | george &  2382
The shell includes job numbers in messages it prints when a background job completes, like this:
 + Done fred &
We'll explain what the plus sign means soon. If the job exits with nonzero status (see Chapter 5), the shell includes the exit status in parentheses:
 + Done(1) fred &
The shell prints other types of messages when certain abnormal things happen to background jobs; we'll see these later in this chapter.
Copyright © 2003 O'Reilly & Associates. All rights reserved.