ideas and questions for implementation of MessageMode in Named Pipes

[Juan Lang]

> i think i've finally come up with an idea that i believe will work:
> double-socketing.
(snip)
> it'll be ok (and desirable) to allow multiple "readers" of the "read"
> socket. what you _don't_ want is more than one reader trying to
> indicate "please start sending a new message" whilst there are other
> reader(s) still grabbing the previous message.
>
> so i believe that a critical section (copying the style of the code
> around server_get_unix_fd) each around "please start a new message"
> and "please send some more read-data" would be sufficient.

Out of curiosity, why is this better than a single socket with the
length of each message prepended?  I'm not advocating that that's a
better approach, mind you.  It just seems to me that, if you're
putting critical sections of a sort into the server anyway, you could
block clients just as easily with one socket as with two.

One difficulty I'm having trouble getting my head around is, isn't the
data removed from a socket once it's ready by any process?  Or does it
remain for each process to read independently?  I guess I'm not that
familiar with how reading from a socket works.  I'd always assumed
that the former was true, and that therefore the only correct approach
would be to buffer message-mode named pipe data in the server.  This
is ugly (and slow), which is why Alexandre's stated preference has
been to push it into the Linux kernel.

For what it's worth, Steve French has expressed interest in doing just
that.  He asked for a clear spec for what filename these sockets
should have, but we didn't have a clear app that we needed to fix, so
we never followed through.  You might approach him again.  He's the
maintainer of the CIFS kernel module for Linux, and he already has his
own named pipe implementation.
--Juan