An Operating Systems Vade Mecum

Inter-process communication 301Ordinary Unix pipes are neither broadcast nor delimiting. They are practicallynever intended for multiple readers or multiple writers. Under these constraints, pipesunify terminal transput with file transput and with process transput. Pipe descriptorsbehave just like file descriptors as far as reading and writing are concerned. They alsobehave just like device descriptors, which are used for transput with the terminal. Thisunification is elegant in that the transput interface between processes and the outsideworld is built entirely on a single concept.Processes expect that they will have two descriptors when they start, one called‘‘standard input’’ and the other ‘‘standard output.’’ Typically, the first is a descriptor tothe terminal open for input, and the second is a similar descriptor open for output. However,the command interpreter, which starts most processes, can arrange for thesedescriptors to be different. If the standard output descriptor happens to be a file descriptor,the output of the process will go to the file, not the terminal. The process does notknow about this substitution and does not care. Similarly, the command interpreter canarrange for the standard output of one process to be one end of a pipe and for the otherend of the pipe to be standard input for a second process. This situation is shown in Figure9.5, where a listing program is piped to a sorting program, which in turn directs itsoutput to a file.2.4 PortsUnix pipes are a special case of a more general inter-process communication mechanismcalled ports. A port is a repository of data being sent from one process to another. It islike an anonymous postal address in the sense that the two processes involved in thecommunication do not need to know anything about each other’s identities.Ports are often used to represent services that one process can offer others. Forexample, many interactive operating systems have a program called Finger that willreport who is logged on. It is sometimes convenient for a user on computer A to invokeFinger on computer B. Both computers can run operating systems that follow an interprocesscommunication convention in which a particular port, say 79, represents theFinger service. The user on machine A runs a program that sends a message asking forthis service to port 79 on computer B. The Finger program spends its idle time blockedtrying to read from this port. When a request arrives, Finger receives it from the port,compiles a list of the users currently logged on, and sends this list back to the program onmachine A. This reply might be directed to a port that the program on computer Aopened just for the purpose of hearing the reply. The original request from A includedterminalListSortfileFigure 9.5 A pipeline of two processes