Fwd: Re: I/O semantics of pipe and FIFO.

an interesting point to discuss? is our behaviour in this test right?
    from: "austin-group mailng list (posix standard discussion)"

------ rest of email is quoted -------
On 5/3/17 5:48 am, Stephane Chazelas wrote:

2017-03-04 13:14:08 +0000, Danny Niu:
> Hi all.
>
> I couldn't remember where I saw it saying, that when reading
> from a pipe or a FIFO, the read syscall returns the content of
> at most one write call. It's a bit similar to the
> message-nondiscard semantics of dear old STREAM.
>
> Currently, I'm reading through the text to find out a bit
> more, and I appreciate a bit of pointer on this.
[...]

(echo x; echo y) | (sleep 1; dd count=1 2> /dev/null)

outputs both x and y in all of Linux, FreeBSD and Solaris in my
tests.

That a read wouldn't read what's currently in the pipe would be
quite surprising.

I also wouldn't expect pipes to store the writes as individual
separate message but use one buffer.

In:

(
   dd bs=40000 count=1 if=/dev/zero 2> /dev/null
   echo first through >&2
   dd bs=40000 count=1 if=/dev/zero 2> /dev/null
   echo second through >&2
) | (sleep 1; dd bs=100000 count=1 2> /dev/null) | wc -c

That is where the second write blocks because the pipe is full,
the reading dd still reads both writes in Linux and Solaris in
my tests (on Solaris (10 on amd64 at least), reduce to 20000
instead of 40000 or both writes would block).

On FreeBSD, I get only the first write (using 8000 followed by
10000 for instance).

FreeBSD is also the only one of the three where

dd bs=1000000 count=1 if=/dev/zero | dd bs=1000000 count=1 | wc -c

Doesn't output 1000000. The others schedule both processes back
and forth during their write() and read() system call while the
pipe is being filled and emptied several times.

-- 
Stephane