Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.lang.c
Subject: Re: Does O_NDELAY shred read(2)?
Keywords: O_NDELAY, read, pipes
Message-ID: <1989Nov13.153109.5943@chinet.chi.il.us>
Date: 13 Nov 89 15:31:09 GMT
References: <20764@ut-emx.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Chicago Public Access UNIX
Lines: 29

In article <20764@ut-emx.UUCP> jon@walt.cc.utexas.edu (Jon Boede) writes:
>If I have two processes communicating through a named pipe, and if the process
>that is read(2)ing has O_NDELAY set on the file descriptor so that it will
>return if nothing is on the pipe...

>If a write(fd,buf,X) is made, will a read(fd2,buf2,X) == X?  In other words, I
>know that the write will be atomic... will the read also be?  Is there a
>certain buffer size past which I'll start running into trouble?  I'm thinking
>of using a buffer that's about 2,000 bytes in length.

Look in limits.h for the size of PIPE_BUF.  This is the maximum size of an
atomic write.  If the writes are within this limit, then reads of an
equal size will either return nothing (with O_NDELAY set) or a complete
buffer as long as the size of the read() matches the size of the corresponding
write().

>Also, with a named pipe, how much (byte-wise) can be written before the writer
>will be suspended?  Does setting O_NDELAY on the write end do anything?

There should also be a #define for PIPE_MAX for this size.  On SysVr3.2 for
the 3B2 and 386, both PIPE_BUF and PIPE_MAX are 5K.  Setting O_NDELAY on
the write end will make a write() return with an error if the write()
request would exceed PIPE_MAX. If the size of the write is less than
PIPE_BUF, nothing is written in that case.  Without O_NDELAY, the write()
would block until the reading side drained the pipe buffer enough to allow
the write() to complete. 

Les Mikesell
 les@chinet.chi.il.us