To answer some of Jim's specific questions:
> I am seeking help in using named pipes to function in the same way as
> message files.  I have a need to have multiple writers and one reader.
> Would someone please direct to some good documentation about named pipes,
> particularly as they are implemented on the 3000?

I can't say whether they are guaranteed to work the same on MPE as on Unix
(thought I would expect so) but here are some answers based on some web
seraching...

> First, Lars mentions that named pipes cannot be written to unless
> there is a reader (this limitation can be overcome).

As a writer, I think you will block on the first write if there is no reader.
This is so that it does not matter in which order the reader and writer open
the pipe.  In Message Files, there is a similar feature where the *reader*
will block on the first read if there is no writer yet (sort of backwards from
the way pipes work).

I don't think there is really a workaround for pipes.  Without a reader, there
is nowhere to send the data.  You can detect the case by doing nonblocking I/O
I suspect, but you'll have to deal with it on your own.

> Secondly, there appears to be some limit of how much data can reside
> in the pipe.  Is that still true and what is that limit?

Yes, a pipe is simply an in-memory buffer that comes into existence when the
pipe is "opened" and disappears when it is closed.  There is no associated
disk space as there is with Message Files.

> My main concern now is to determine that if I have multiple writers to a
> named pipe will one writer's data be entered completely before allowing the
> second writer's data to begin writing

The answer seems to be that there is a constant PIPE_BUF which defines the
largest write() call that you can make that is guaranteed to be atomic.  On
Linux this constant is in <linux/limits.h> and has a vlue of 4096 which is
probably fairly typical.

I *suspect* that this value (4096) is also the maximum amount of data that can
be in a pipe.

If you write() no more than this amount, it will not be interleaved with
writes by other users who also have the pipe open.  If you try to write
exactly 4096 bytes when there is *any* unread data in the pipe, my guess is
that you block until the pipe is completely empty and so has room for the
whole block of data.

If you try to write more than PIPE_BUF bytes, then the write will accept some
of the data (probably PIPE_BUF bytes) and return the number of bytes written.
You would then have to make a second write() call for the remainder of the
data.  There is apparently no guarantee of ordering or atomicity in this case.

Once again, pipes turn out to make rather lousy Message Files.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *