Must really be safe_read(), not full_read()? (was: [PATCH] fix httpd lockup in cgi POSTs)

[Rob Landley]

On Tuesday 13 February 2007 8:58 am, Paul Albrecht wrote:
> However, I still think that because the read syscall is unbuffered you
> can't assume that if you write x bytes to one end of the pipe you're
> guaranteed x bytes on the *first* read on the other end of the pipe.

http://www.opengroup.org/onlinepubs/009695399/functions/write.html

  After a write() to a regular file has successfully returned:
    o Any successful read() from each byte position in the file that was
      modified by that write shall return the data specified by the write()
      for that position until such byte positions are again modified.

  Write requests to a pipe or FIFO shall be handled in the same way as a
  regular file with the following exceptions:
    o There is no file offset associated with a pipe, hence each write request
      shall append to the end of the pipe.
    o Write requests of {PIPE_BUF} bytes or less shall not be interleaved with
      data from other processes doing writes on the same pipe.

Yes, you can.

> I think you're supposed to check the number of bytes read and continue
> doing reads until you get as much data as you're expecting or get end of
> file.

A pipe is attached to a kernel buffer which his updated atomically by write() 
and read() syscalls.  There is _cannot_ be any propogation delay, nor partial 
writes of less than PIPE_BUF, in an SUSv3 compliant pipe implementation.  The 
spec says so.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery