Re: Named Pipe patch

[Alexandre Julliard]

Mike McCormack  writes:
> The patch moves away from using unix pipes to implement named pipes,
> and instead implements pipes internally. This is necessary to
> implement message mode properly (without race conditions).

Could you explain this a bit more?  Why can't you use a datagram socket
for message mode?  I think we really want to avoid doing I/O through
the server, our I/O is already slow enough as it is...

Named Pipe patch

[Dan Kegel]

Alexandre Julliard wrote:
> Mike McCormack  writes:
> > The patch moves away from using unix pipes to implement named pipes,
> > and instead implements pipes internally. This is necessary to
> > implement message mode properly (without race conditions).
>
> Could you explain this a bit more?  Why can't you use a datagram socket
> for message mode?  I think we really want to avoid doing I/O through
> the server, our I/O is already slow enough as it is...

Datagram sockets are unreliable, aren't they?

How about Posix message queues?  Oh, wait, Linux doesn't seem
to have those.  (Guess it's time to add posix message queue
tests to the LTP :-> )

- Dan

Named Pipe patch

[Alexandre Julliard]

Dan Kegel  writes:
> Datagram sockets are unreliable, aren't they?

Across the network yes, but in the unix domain we can hope that they
won't lose messages.

Named Pipe patch

[Mike McCormack]

Hi Alexandre,

Well, we need to support :

* peeking on a message
* switching between message and byte mode at any time
* reads that stop after reading a single message from a queue even if
   there's more data
* interfacing to possibly remote named pipe ends

After reading the unix(7) man page, it seems they are close to what we 
want... however I'm not sure that we can do switching between message 
and byte mode properly.

Unix DGRAMS are apparently reliable and order preserving, so at least 
that isn't a problem.

Mike

Alexandre Julliard wrote:
> Could you explain this a bit more?  Why can't you use a datagram socket
> for message mode?  I think we really want to avoid doing I/O through
> the server, our I/O is already slow enough as it is...