[TUHS] Pipes on Eunice

[Clem Cole via TUHS]

>
> The docs still exist: https://vtda.org/docs/computing/TheWollongongGroup/


On Mon, Dec 29, 2025 at 11:55 AM Paul Winalski via TUHS <tuhs at tuhs.org>
wrote:

> I assume that Eunice implemented Unix pipes.  If so, how?  Did they have
> their own pipe device driver?
>
> -Paul W.
>
EUNICE BSD Reference Manual August 1988 [pg 32]


3.2.2 *Pipes*

UNIX pipes are implemented using VMS mailboxes (a virtual 1/0 device). The
default mailbox size

used by EUNICE BSD is 512 bytes. Therefore, writes to a pipe will block
once there are 512 bytes

waiting to be read from the pipe (in UNIX the quantity is 4096 bytes). It
is extremely rare for a

UNIX program to use the fact that it may write 4096 bytes without blocking.
In this case, the user has

the option of going into the EUNICE BSD data structures at run time and
changing the default

mailbox size to 4096 bytes. †


Since mailboxes provide a more general interprocess communication
(IPC) mechanism
than UNIX

pipes, a non-UNIX IPC facility is also provided with EUNICE BSD. This
facility allows for pipe-like

objects on which the user can perfonn *read *and *write *operations
identical to those on pipes. The *write*

operation guarantees that the buffer written will be delivered through the
IPC facility as a single atomic

entity (as long as the buffer is no larger than the maximum message length
specification for the

mailbox -- which is under the control of the program creating the mailbox).

Unlike UNIX pipes, these objects need not be inherited from a parent
process. They are given unique

names which programs may use with the *open *call to gain access to a given
IPC object. Access

pennission to these objects may be specified by the creating program
in the same
way that access

pennissions to files are specified. The creating program may also give
these objects specific names

which are recognized locally (to a specific group of processes) or globally (to
the entire system); this

greatly simplifies the task of creating and communicating with specialized
setver processes. Typically,
a user might create a uniquely named IPC object, open a globally named IPC
object for access to a

server, and then pass the name of its entity in a message to the server for
a reply channel.



†A file of "C" definitions of all internal EUNICE BSD data structmes is
included with EUNICE BSD so that users *who *

require the ability to manipulate the internal state of EUNICE BSD or who
wish to add/replace routines in EUNICE BSD ·· .. "

may do so.