Interprocess Communication

September 28, 2016

The process idealization provides an environment. For the process to affect the world, processes must work together exchanging information and the timing of events. Process often exchange information through files, as well as having the process exchange information with itself, displaced in time, when information is placed in a file for retrieval later, or when instances of the process are stopped and restarted to continue on with the process achieved up to the stopping point. Although files are a method of interprocess communication, we discuss them under the heading of persistence, as their primary feature is that they persist and have a system of cataloging.

The methods of process communication discussed here are mechanisms of interprocess communication that can be interactive and are more immediate and fluid.

Unix V6 provided for a unified structure on information flows, as seeing as an almost sufficient model of information flow as the stream of bytes. For historical reasons, the unit of information coalesced around the 8 bit byte, and recognizing the importance of interrelationships between those bytes, unix idealizes information as a strict sequence of those bytes, one after the other, where the sequence is as important as the actual data values. Their were no requirements on the rhythm of the flow, and the arrival of a byte, not its contents, can in fact be the content of the message.

While protocols more generally are discussions between processes, with information flowing interactively in both directions, the unix model saw as basic a one-way flow, called half-duplex, after historical terminology dating back to the teletype. A bundle of two half-duplex channels, in opposite directions, formed and full-duplex channel that allows for "discussion" between the processes. Their is no real timing mechanism assured between the two halves of a duplex channel. Although bytes entered into a channel should arrive at the outlet in a timely fashion, that is an expectation, and will not be a promise.

Unix V6 also provided signals, which are specifically designed to communicate by the occurrence of an event, with little channel width to parameterize the conditions of the event, just that it happened. This model is useful for its low overhead, lack of setup steps, and when the sender’s role is more facilitory than constructive — the sender of a signal needs only the receiving process’ PID and the right to send; the receiver can do as it pleases with the signal, and the receiver has no obligations to the sender for having been the target of a signal.

Signals are sent by the kill system call. The call takes two parameters, the process ID of the process to receive the signal, and a numeric identifier for the signal. The event of a signal is noted by setting flags in the process’ process control block (PCB), and at any point that the kernel returns to a thread in the process these flags are checked and if signaled the kernel arranges to return into a signal handler, rather than the interrupted flow of code.

Many signals have meanings that are defined by a standard. For instance, the SIGKILL signal indicating that the sender is asking that the process terminate immediately. Numerically, SIGKILL is 9. There is a signal handler installed into all processes to receive the kill 9 and to exit the process. Most signals either have no handler, or the handler provided by default can be overridden. The kill 9 handler cannot be overridden.

The Unix Pipe

Two process can communicate through a byte stream channel, a construction called a pipe. In unix, pipes are constructed naturally because the standard input and output are modeled as byte streams. One process can produce bytes into its standard out and another process can consume those bytes from its standard in. A unix feature was the simple construction of such connections between programs written to consumer bytes from standard in and produce bytes to standard out using a command line notation. For instance, the program ls produced a directory listing to standard out, and the program wc counted words consumed from standard in. Therefore piping standard out of ls to standard in of wc gave a combination program that would count the numbers of files in a directory.

That simple notation used the pipe symbol as so: ls | wc .

The byte stream channel includes an additional signal for end of file (EOF). In the above example, not only does ls communicated to wc a sequence of file names, it signals to when that list is ended. This is not represented in band, that is, there is not a byte marker sent that indicates no more bytes follow, even though the ASCII standard does provide for such a byte marker int the EOF character, a.k.a. control-D, but by an out of band mechanism that signals and EOF condition.

This simple model of communication as a byte stream influenced the file system interface. A file is any element of data persistence, but in the standard unix models of read and write is a source or sink, respectively, of a byte stream. This is true when a file is accessed by the read or write system call inside a program, or when a file is attached to the standard in or standard out of a program. This is called file redirection an on the command line is indicated with the less than or greater than characters. For instance, to list the directory into the file f.txt, use the unix syntax: ls > f.txt ; and to word cout from the file f.txt, use the unix syntax: wc < f.txt , or alternatively: cat f.txt | wc .

There is a slight bit of magic in making this work. The ls program knows to what type of sink it is providing characters, and according to the type, will provide the output formatted differently. When providing output to the terminal, the listing is formatted in user-convenient columns. But when provided into a pipe or file, the listing is formatted in machine friendly one filename per line.

Other Communication Mechanisms

  • Pipes
  • Named pipes
  • sockets

posted in CSC521 by admin

Powered by Wordpress and MySQL. Theme by Shlomi Noach,