next up previous top
Next: PLBundler
Up: Connector Type
Previous: FileIO



The connector type Pipe provides an architectural abstraction for a Unix pipe. It can establish interaction between two Filter components, or between a Filter component and a
SeqFile component. The Pipe connector establishes a data flow interaction. Data either flows from one filter to another, or it flows from a filter to a file (or vice versa). Depending on the type of interaction, the UniCon compiler chooses the correct implementation mechanism to realize the connection in the final system.

The system designer, however, may choose to constrain the implementation mechanism for data flowing between two filters by specifying the PipeType property in the protocol property list. The implementation mechanism that UniCon chooses in this case is a Unix mechanism called a pipe. A pipe is literally a buffer used to store data temporarily as it flows from one process to another. Pipes can be implemented in two ways in Unix: as relatively small, unnamed buffers internal to the Unix operating system, or as named files that exist in the file system. The advantage of using files over internal Unix buffers is that they are much larger in size. For all intents and purposes, they are virtually unconstrained, whereas the internal Unix buffers for unnamed pipes are small (4K to 8K bytes, depending on the system). Advantages to using the internal buffers over files is that they are less cumbersome to implement and more efficient at run-time. The system designer can use the PipeType property to specify the use of Named (files) or Unnamed (internal buffers) pipes.

Role types

Roles of the following types can be legally defined in the protocol of a connector of type Pipe:

a reader of the data in the pipe
a writer of data to the pipe


The following properties can be legally included in the property list of a connector of type Pipe. Properties legal in a <protocol> property list have a P in parentheses after the property name; those legal in an <instantiation> or <establish> property list have an I:

The syntax for an InstFormals property in a connector of type Pipe is a comma-separated list of <parameter>s enclosed in parentheses. A <parameter> consists of an <identifier>, followed by a `=', followed by a <complex string> or the language keyword NODEFAULT. A <complex string> is a simple "string" or a sequence of "string"s concatenated by the `&' character:

INSTFORMALS (first_parameter = "an initial value",
second_parameter = "a much" &
"longer initial value that " &
"will not fit on one line",
third_parameter = NODEFAULT)
The syntax for a PipeType property in a connector of type Pipe is one of the two keywords Named or Unnamed, (optionally) enclosed in double-quotes, and surrounded by parentheses:

PIPETYPE (named)
PIPETYPE ("unnamed")

If no PipeType property is specified in the protocol property list of a Pipe connector, the default value is "named".

Semantic Checks

The following are the semantic checks made in connections of type Pipe:

  1. Even if the MaxConns property associated with either the Source or the Sink role in a Pipe connector allows more than one connection to that role, UniCon enforces the restriction that a maximum of one connection to either of these roles is permitted.

  2. If the Pipe connection establishes interaction between two Filter components, then the data type in the signature of the player playing the Source role must be identical (including case) to the data type in the signature of the player playing the Sink role. (Warning only)

  3. If the Pipe connection establishes interaction between a Filter and a SeqFile, then the data type in the Signature of the StreamIn or StreamOut player must be identical (including case) to the data type in the RecordFormat of the SeqFile component in which the ReadNext or WriteNext player is defined. Additionally, the RecordFormat property may not contain more than one data type. (Warning only)

  4. A Pipe connection must contain at least one Filter component (i.e., it may not connect two SeqFile components).

Implementation Semantics

As described above, the Pipe connector may establish interaction between two Filters, or a Filter and a SeqFile. Depending upon the type of interaction, Pipe connections are realized by different mechanisms in the underlying implementation of the system. If establishing interaction between two Filters, Pipe connections in the implementation are realized as calls to the pipe, mkfifo, or mknod C library routines. The calls to pipe create unnamed pipes in the Unix environment that implement the Pipe connection, and the calls to mknod and mkfifo create named pipes.

Unnamed pipes are nameless buffers in the Unix operating system environment that have a fixed size (usually between 4K and 8K bytes, depending on your system). Unnamed pipes implement the following semantics:

The call to pipe returns two file descriptors, one opened for reading and the other for writing, which provide access to the buffer. The buffer is circular. Data is written sequentially and follows previously written bytes. When the buffer fills up, the process performing the write operations is suspended until data is read from the pipe and space becomes available in the buffer. When this happens, the writing process is resumed by the operating system and continues writing. Data is read from the buffer sequentially, in the order that the bytes were written. If all of the data in the buffer has been read and the reading process wishes to continue reading data, then the reading process is suspended until more data is written to the pipe. When this happens, the reading process is resumed and continues. If the writing process closes its end of the pipe, the reading process will receive an EOF after all data has been read from the buffer. If the reading process closes its end of the pipe, the writing process will receive a SIGPIPE signal from the operating system.

Named pipes are implemented as named files in the operating system. The advantage to using a named pipe instead of an unnamed pipe is that the size of the buffer is virtually unlimited, since the size of a file in the file system is unlimited (for all practical purposes). The semantics of the behavior of a named pipe are identical to the semantics of an unnamed pipe, except that each process must open the file after it is created by the call to mkfifo or mknod (one must open it for reading, and the other for writing), and the writing process is suspended after opening it until another process opens it for reading (and vice versa).

The implementation of named and unnamed pipes in the final system is transparent to the system designer. The only difference between named and unnamed pipes discernible to the system designer is the behavior of a pipe at run-time - the amount of data that can flow through a pipe during system execution.

If establishing interaction between a Filter and a SeqFile, a Pipe connection is realized by a call to the open C library routine in the process implementing the Filter. This call opens the file implementing the SeqFile for reading and/or writing, as specified in the UniCon description. Again, the implementation of this mechanism in the final system is transparent to the system designer.

When a system is constructed of many pipes, filters, and files, the UniCon compiler creates an initialization routine that, at run-time, creates all the pipes and starts up the filters with all the proper port bindings. It handles arbitrary topologies correctly.

next up previous top
Next: PLBundler
Up: Connector Type
Previous: FileIO

Comments? Mail the current maintainer of this page.

Author: Gregory Zelesnik

Last Modified: May 12, 1996