[TUHS] Pipes on Eunice

[Paul Winalski via TUHS]

On Mon, Dec 29, 2025 at 12:38 PM Clem Cole <clemc at ccc.com> wrote:

>
> 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.
>

Thanks, Clem.  I suspected that they might use VMS mailboxes to implement
pipes.   It certainly is the VMS feature closest in behavior to pipes.  But
mailboxes differ from pipes in some key aspects.

As mentioned in the EUNICE doc excerpt quoted above, there is a size
associated with VMS mailboxes and when the mailbox is full the process
issuing the write operation is stalled until some data are read from the
mailbox.  This happens on Unix, too, with pipes.  But on VMS the writing
process is stalled in a particularly nasty way.  It is placed into a
resource wait state called RWMBX (resource wait mailbox full).  When that
happens the stalled process can't be deleted until it leaves RWMBX state.
Your process hangs until some data are read from the mailbox.  This can be
nasty.

The pipe(2) call returns two file descriptors, one for the read end of the
pipe and the other for the write end.  The equivalent system call in VMS is
$CREMBX, which creates a mailbox and assigns an I/O channel (VMS equivalent
of a file descriptor) to it.  To emulate pipe(2) one would have to assign a
second channel to the mailbox.  But the catch is that these channels are
bidirectional--you can read or write to either of them.  This has a bad
consequence:

You can't do broken pipe detection using mailboxes.  With Unix pipes a read
will report a "broken pipe" error if the file descriptor for the write end
of the pipe is closed.  Conversely, a write will report a "broken pipe"
error if the file descriptor for the write end of the pipe is closed.  I/O
channels assigned to a mailbox aren't read-only or write-only.  You can't
tell if you're writing but there are no readers, or reading and there are
no writers.

In the mid-1980s DEC did a port of the Unix Bourne shell to VMS.  This was
marketed under the name DEC Shell.  We (VMS Languages and Software
Development Tools Group) were aware of these two behavioral differences as
well as other gotchas when you try to use mailboxes as pipes.  We ended up
cloning the mailbox device driver code and tweaking it to implement true
Unix pipe behavior.  It did not place your process into an uninterruptible
resource wait state if the pipe filled up--you got a conventional
wait-for-I/O-completion.  I/O channels assigned to the pipe were tagged as
read-only or write-only based on the first I/O operation done to them.
This allowed for "broken pipe" detection.  This pipe device driver shipped
along with DEC Shell, which otherwise was non-privileged.

-Paul W.