An Operating Systems Vade Mecum

The command interpreter 241command interpreter notices that the process has stopped and resumes its own execution.(If the command interpreter is a utility process, it might have executed a service call‘‘wait for this process to stop.’’) We discuss process control more fully in Chapter 9.Some operating systems allow a process to stop in such a way that it can beresumed later. This feature allows the user to alternate attention among severalprocesses. For example, during program preparation the user frequently switchesbetween editing and compiling. One process might be a text editor manipulating a Fortranprogram. When a change has been made to the program, the editor might bestopped, the run command given to the command interpreter, and the results of executionexamined. Then the user could resume the editor and try to figure out why the programbehaved the way it did. It is not necessary to reinvoke the editor, an action thatmight take much longer than resuming it.Another example comes from inter-user mail. A user often reads new mail as partof the ritual of starting an interactive session. If an entry in the mailbox requires immediateattention, the user might stop the program that reads mail, direct attention to thatpressing matter, then resume the program and read the rest of the mail.It is not uncommon on such operating systems for one user to have five or tenprocesses, all but one of which are stopped. The command language might provide commandsto list the stopped processes and to resume any one of them. One way to depict aparticular process is to display the command that started it in the first place.Under many operating systems, processes can be started either by the commandinterpreter or by other processes. This latter kind is not directly under the control of thecommand interpreter. For example, the user might type transfer #d #fake#log file.old to tell the Transfer program to delete file.old in the carefulmanner that copies it to another directory. The #log flag tells Transfer to record thisaction in a logging file. Instead of performing these operations sequentially, let us supposethat Transfer itself invokes two processes, one to move the file and the other tocreate a log entry. A single command has thereby created the beginnings of a tree ofprocesses, which looks like Figure 7.1. In turn, ‘‘move’’ and ‘‘log’’ might generate otherprocesses. This particular scenario is a bit forced, but remarkably many programs useother processes to do work for them under operating systems that allow this feature. Theoptional ‘‘sort’’ utility, which is used in many applications, is often invoked as a subprocessby such disparate programs as Transfer with the #list flag, which is asked to listall the files in the directory (sorted alphabetically) and ‘‘checkspelling,’’ which mightfirst sort all the words in the file that is to be checked, removing duplicates, in order toreduce the number of words that must be searched in the dictionary.transferlogFigure 7.1 A process treemove