Introductory 4.4BSD IPC PSD:20-1An Introductory 4.4BSDInterprocess Communication TutorialStuart SechrestComputer Science Research GroupComputer Science DivisionDepartment of Electrical Engineering and Computer ScienceUniversity of California, BerkeleyABSTRACTBerkeleyUNIX† 4.4BSD offers several choices for interprocess communication. To aid the pro-grammer in developing programs which are comprised of cooperating processes, the different choices arediscussed and a series of example programs are presented. These programs demonstrate in a simple waythe use of pipes, socketpairs, sockets and the use of datagram and stream communication. The intent of thisdocument is to present a fewsimple example programs, not to describe the networking system in full.1. GoalsFacilities for interprocess communication (IPC) and networking were a major addition to UNIX inthe BerkeleyUNIX 4.2BSD release. These facilities required major additions and some changes to the sys-tem interface. The basic idea of this interface is to makeIPC similar to file I/O. In UNIX a process has aset of I/O descriptors, from which one reads and to which one writes. Descriptors may refer to normal files,to devices (including terminals), or to communication channels. The use of a descriptor has three phases:its creation, its use for reading and writing, and its destruction. By using descriptors to write files, ratherthan simply naming the target file in the write call, one gains a surprising amount of flexibility.Often, theprogram that creates a descriptor will be different from the program that uses the descriptor.For examplethe shell can create a descriptor for the output of the ‘ls’ command that will cause the listing to appear in afile rather than on a terminal. Pipes are another form of descriptor that have been used in UNIX for sometime. Pipes allowone-way data transmission from one process to another; the twoprocesses and the pipemust be set up by a common ancestor.The use of descriptors is not the only communication interface provided by UNIX. The signal mech-anism sends a tinyamount of information from one process to another.The signaled process receivesonlythe signal type, not the identity of the sender,and the number of possible signals is small. The signalsemantics limit the flexibility of the signaling mechanism as a means of interprocess communication.The identification of IPC with I/O is quite longstanding in UNIX and has provedquite successful. Atfirst, however, IPC was limited to processes communicating within a single machine. With BerkeleyUNIX4.2BSD this expanded to include IPC between machines. This expansion has necessitated some change inthe way that descriptors are created. Additionally,new possibilities for the meaning of read and write havebeen admitted. Originally the meanings, or semantics, of these terms were fairly simple. When you wrotesomething it was delivered. When you read something, you were blocked until the data arrived. Other pos-sibilities exist, however. One can write without full assurance of delivery if one can check later to catchoccasional failures. Messages can be kept as discrete units or merged into a stream. One can ask to read,†UNIX is a trademark of AT&T Bell Laboratories.PSD:20-2 Introductory 4.4BSD IPCbutinsist on not waiting if nothing is immediately available. These newpossibilities are allowed in theBerkeleyUNIX IPC interface.Thus BerkeleyUNIX 4.4BSD offers several choices for IPC. This paper presents simple examplesthat illustrate some of the choices. The reader is presumed to be familiar with the C programming language[Kernighan & Ritchie 1978], but not necessarily with the system calls of the UNIX system or with pro-cesses and interprocess communication. The paper reviews the notion of a process and the types of com-munication that are supported by BerkeleyUNIX 4.4BSD. Aseries of examples are presented that createprocesses that communicate with one another.The programs showdifferent ways of establishing channelsof communication. Finally,the calls that actually transfer data are reviewed. Toclearly present howcom-munication can takeplace, the example programs have been cleared of anything that might be construed asuseful work. Theycan, therefore, serveasmodels for the programmer trying to construct programs whichare comprised of cooperating processes.2. ProcessesA program is both a sequence of statements and a rough way of referring to the computation thatoccurs when the compiled statements are run. A process can be thought of as a single line of control in aprogram. Most programs execute some statements, go through a fewloops, branch in various directionsand then end. These are single process programs. Programs can also have a point where control splits intotwoindependent lines, an action called forking. In UNIX these lines can neverjoin again. A call to thesystem routine fork(),causes a process to split in this way.The result of this call is that twoindependentprocesses will be running, executing exactly the same code. Memory values will be the same for all valuesset before the fork, but, subsequently,each version will be able to change only the value of its own copyofeach variable. Initially,the only difference between the twowill be the value returned by fork(). The par-ent will receive a process id for the child, the child will receive a zero. Calls to fork(), therefore, typicallyprecede, or are included in, an if-statement.Aprocess views the rest of the system through a private table of descriptors. The descriptors can rep-resent open files or sockets (sockets are communication objects that will be discussed below). Descriptorsare referred to by their indexnumbers in the table. The first three descriptors are often known by specialnames, stdin, stdout and stderr.These are the standard input, output and error.When a process forks, itsdescriptor table is copied to the child. Thus, if the parent’sstandard input is being taken from a terminal(devices are also treated as files in UNIX), the child’sinput will be taken from the same terminal. Whoeverreads first will get the input. If, before forking, the parent changes its standard input so that it is readingfrom a newfile, the child will takeits input from the newfile. It is also possible to takeinput from a socket,rather than from a file.3. PipesMost users of UNIX knowthat theycan pipe the output of a program ‘‘prog1’’tothe input ofanother,‘‘prog2,’’ bytyping the command ‘‘prog1|pro g
View Full Document
Unlocking...