Introductory 4 4BSD IPC PSD 20 1 An Introductory 4 4BSD Interprocess Communication Tutorial Stuart Sechrest Computer Science Research Group Computer Science Division Department of Electrical Engineering and Computer Science University of California Berkeley ABSTRACT Berkeley UNIX 4 4BSD offers several choices for interprocess communication To aid the programmer in developing programs which are comprised of cooperating processes the different choices are discussed and a series of example programs are presented These programs demonstrate in a simple way the use of pipes socketpairs sockets and the use of datagram and stream communication The intent of this document is to present a few simple example programs not to describe the networking system in full 1 Goals Facilities for interprocess communication IPC and networking were a major addition to UNIX in the Berkeley UNIX 4 2BSD release These facilities required major additions and some changes to the system interface The basic idea of this interface is to make IPC similar to file I O In UNIX a process has a set 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 rather than simply naming the target file in the write call one gains a surprising amount of flexibility Often the program that creates a descriptor will be different from the program that uses the descriptor For example the shell can create a descriptor for the output of the ls command that will cause the listing to appear in a file rather than on a terminal Pipes are another form of descriptor that have been used in UNIX for some time Pipes allow one way data transmission from one process to another the two processes and the pipe must be set up by a common ancestor The use of descriptors is not the only communication interface provided by UNIX The signal mechanism sends a tiny amount of information from one process to another The signaled process receives only the signal type not the identity of the sender and the number of possible signals is small The signal semantics 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 proved quite successful At first however IPC was limited to processes communicating within a single machine With Berkeley UNIX 4 2BSD this expanded to include IPC between machines This expansion has necessitated some change in the way that descriptors are created Additionally new possibilities for the meaning of read and write have been admitted Originally the meanings or semantics of these terms were fairly simple When you wrote something it was delivered When you read something you were blocked until the data arrived Other possibilities exist however One can write without full assurance of delivery if one can check later to catch occasional 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 IPC but insist on not waiting if nothing is immediately available These new possibilities are allowed in the Berkeley UNIX IPC interface Thus Berkeley UNIX 4 4BSD offers several choices for IPC This paper presents simple examples that 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 processes and interprocess communication The paper reviews the notion of a process and the types of communication that are supported by Berkeley UNIX 4 4BSD A series of examples are presented that create processes that communicate with one another The programs show different ways of establishing channels of communication Finally the calls that actually transfer data are reviewed To clearly present how communication can take place the example programs have been cleared of anything that might be construed as useful work They can therefore serve as models for the programmer trying to construct programs which are comprised of cooperating processes 2 Processes A program is both a sequence of statements and a rough way of referring to the computation that occurs when the compiled statements are run A process can be thought of as a single line of control in a program Most programs execute some statements go through a few loops branch in various directions and then end These are single process programs Programs can also have a point where control splits into two independent lines an action called forking In UNIX these lines can never join again A call to the system routine fork causes a process to split in this way The result of this call is that two independent processes will be running executing exactly the same code Memory values will be the same for all values set before the fork but subsequently each version will be able to change only the value of its own copy of each variable Initially the only difference between the two will be the value returned by fork The parent will receive a process id for the child the child will receive a zero Calls to fork therefore typically precede or are included in an if statement A process views the rest of the system through a private table of descriptors The descriptors can represent open files or sockets sockets are communication objects that will be discussed below Descriptors are referred to by their index numbers in the table The first three descriptors are often known by special names stdin stdout and stderr These are the standard input output and error When a process forks its descriptor table is copied to the child Thus if the parent s standard input is being taken from a terminal devices are also treated as files in UNIX the child s input will be taken from the same terminal Whoever reads first will get the input If before forking the parent changes its standard input so that it is reading from a new file the child will take its input from the new file It is also possible to take input from a socket rather than from a file 3 Pipes Most users of UNIX know that they can pipe the output of a program prog1 to the input of another prog2 by typing the command prog1 prog2 This is called piping the output of one program to another because the
View Full Document
Unlocking...