Browse Prior Art Database

Implementation and Performance of Pipes in the V-System

IP.com Disclosure Number: IPCOM000128281D
Original Publication Date: 1985-Dec-31
Included in the Prior Art Database: 2005-Sep-15
Document File: 12 page(s) / 42K

Publishing Venue

Software Patent Institute

Related People

Willy Zwaenepoel: AUTHOR [+3]

Abstract

This paper compares the measured performance of pipes implemented by a pipe server process on top of the V message passing transport protocol vs. the calculated performance of pipes implemented by an operating system kernel and supported by a dedicated protocol.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 9% of the total text.

Page 1 of 12

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

Implementation and Performance of Pipes in the V-System

Willy Zwaenepoel

Rice COW TR85-14

March 1985

Department of Computer Science Rice University P.O. Box 1892 Houston, TX 77251-1892

(713) 527-8101

Abstract

This paper compares the measured performance of pipes implemented by a pipe server process on top of the V message passing transport protocol vs. the calculated performance of pipes implemented by an operating system kernel and supported by a dedicated protocol.

We define the semantics of pipes, describe their implementation in the V-System and present meas-urements of their performance. We then calculate the performance of pipes, when implemented in the ker-nel and supported by a dedicated protocol. The performance loss as a result of using the pipe server is shown to be about 5 percent for network pipes and about 25 percent for local pipes.

Given these figures and given the fact that messages and not pipes are the principal means of inter-process communication in V, we conclude that it is quite practical to implement pipes by a process using message passing, thereby avoiding the need for additional kernel and protocol complexity.

1. Introduction

The pipe facility, as introduced by Unix [7], provides a reliable one-directional byte stream as a means for communicating between processes. Typically, a process creates a pipe and forks two children, which then become the reader and the writer of the pipe. The limitations of pipes as a general interprocess com-munication mechanism have been well documented. In particular, the fact that both ends of the pipe have to have common ancestry precludes programming in the client-aerver paradigm, quite popular in dis-tributed systems. Modern interprocess communication facilities typically espouse the client-server philoso-phy, either under the form of remote procedure calls [21 or under some of form of message-passing [4,5]. Servers provide procedure bodies, which are then invoked by clients, or similarly, clients send messages and servers receive messages and reply to them.

Nevertheless, pipes remain an elegant facility for program composition, in particular for filter pro-grams. A filter is a program that, in Unix terminology, copies its standard input (with some transforma, tion) to its standard output. Several of these filters can be set up in a pipeline. This form of interprocess communication is essentially client-to-client and is not directly supported in

Rice University Page 1 Dec 31, 1985

Page 2 of 12

Implementation and Performance of Pipes in the V-System

interprocess communication systems that provide client-server style primitives. When faced with the problem of implementing pipes in a client-server based system, two solutions come to mind. The first solution consists of introducing a pipe server process between two clients that want to communicate over a pipe. The clients then use the interprocess communication f...