Date: Sun, 5 Mar 2017 11:44:36 +0800 From: Julian Elischer <julian@elischer.org> To: freebsd-current <freebsd-current@freebsd.org> Subject: Fwd: Re: I/O semantics of pipe and FIFO. Message-ID: <8efdc961-1768-0bc0-715f-4a1e103359d4@elischer.org> In-Reply-To: <20170304214812.GA16845@chaz.gmail.com> References: <20170304214812.GA16845@chaz.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8efdc961-1768-0bc0-715f-4a1e103359d4>