Devin and I found this when we worked together. I think it was due to some situation in dd(1) where short reads would exit pre-maturely, however I may be mis-remembering. Devin, do you recall the specifics?


On 3/4/17 7:44 PM, Julian Elischer wrote:

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.


_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to