>>> I have two processes reading from the same named pipe.
>>> The output written to the pipe seems to get evenly split between
>>> the two processes.

>> Feature, I would say.  Traditional pipes have always worked this
>> way, as have sockets.  And (I just now tried it on SunOS 4.1.3)
>> named pipes do this under at least one other OS.

> Note that the consumers do NOT necessarily get round-robin access.

Of course not.  As you point out, they are round-robined only with
respect to any other consumers that happen to be blocked reading from
that pipe at the same time.

> I can think of a few situations where it would make sense to do the
> above.

I have seen something similar used with UDP-based network servers,
where a request can take a long time to process but many requests can
be overlapped: the server forks multiple processes, and each process
blocks in recvfrom().  Incoming requests then get parceled out to the
servers as they become ready to process them.

Of course, for this to work some conditions have to hold:

(1) The servers are all equivalent (since there's a priori way of
     knowing which server a given request will get)

(2) Each blocking I/O call gets an integer number of requests

The biggest difference between multiple processes doing read()s from a
named pipe and multiple processes doing UDP recvfrom()s is that
condition (2) doesn't hold - unless requests are only one byte long,
which is unlikely in practice, one process is liable to read part of a
request and another process the remainder.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu