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 _______________________________________________ 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"
