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.
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.
Author:
Last Modified: May 12, 1996