From owner-freebsd-current@freebsd.org Sun Mar 5 03:44:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D158CF86B8 for ; Sun, 5 Mar 2017 03:44:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BFF91E74 for ; Sun, 5 Mar 2017 03:44:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (106-68-109-205.dyn.iinet.net.au [106.68.109.205]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v253ihoh040516 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 4 Mar 2017 19:44:50 -0800 (PST) (envelope-from julian@elischer.org) Subject: Fwd: Re: I/O semantics of pipe and FIFO. References: <20170304214812.GA16845@chaz.gmail.com> To: freebsd-current From: Julian Elischer X-Forwarded-Message-Id: <20170304214812.GA16845@chaz.gmail.com> Message-ID: <8efdc961-1768-0bc0-715f-4a1e103359d4@elischer.org> Date: Sun, 5 Mar 2017 11:44:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170304214812.GA16845@chaz.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 05 Mar 2017 03:52:27 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 03:44:54 -0000 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