From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 07:59:59 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9186C106566C; Wed, 1 Aug 2012 07:59:59 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 612BE8FC14; Wed, 1 Aug 2012 07:59:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q717xv2x083525; Wed, 1 Aug 2012 07:59:58 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5018E1FC.4080609@gmail.com> Date: Wed, 01 Aug 2012 15:59:56 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:59:59 -0000 On 2012/8/1 15:19, Konstantin Belousov wrote: > On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: >> POSIX requires write() to return actually bytes written, same rule is >> applied to read(). >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html >>> ETURN VALUE >>> >>> Upon successful completion, write() [XSI] and pwrite() shall >>> return the number of bytes actually written to the file associated >>> with fildes. This number shall never be greater than nbyte. >>> Otherwise, -1 shall be returned and errno set to indicate the error. >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>> RETURN VALUE >>> >>> Upon successful completion, read() [XSI] and pread() shall return >>> a non-negative integer indicating the number of bytes actually read. >>> Otherwise, the functions shall return -1 and set errno to indicate >>> the error. > Note that the wording is only about successful return, not for the case > when error occured. I do think that if fo_read() returned an error, and > error is not of the kind 'interruption', then the error shall be returned > as is. I do think data is more important than error code. Do you think if a 512 bytes block is bad, all bytes in the block should be thrown away while you could really get some bytes from it, this might be very important to someone, such as a password or a bank account, this is just an example, whether filesystem works in this way is irrelevant. While program continues to execute, next read()/write() should return -1 and errno will be set, I think both socket and pipe already work in this way, it is dofileread/dofilewrite have made it not happen. >> I have following patch to fix our code to be compatible with POSIX: > ... > >> -current only resets error code to zero for short write when code is >> ERESTART, EINTR or EWOULDBLOCK. >> But this is incorrect, at least for pipe, when EPIPE is returned, >> some bytes may have already been written. For a named pipe, I may don't >> care a reader is disappeared or not, because for named pipe, a new >> reader can come in and talk with writer again, so I need to know >> how many bytes have been written, same is applied to reader, I don't >> care writer is gone, it can come in again and talk with reader. So I >> suggest to remove surplus code in -current's dofilewrite() and >> dofileread(). > Then fix the pipe code, and not introduce the behaviour change for all > file types ? see above, I think data is more important than error code, and next read/write will get the error. >> For EPIPE, We still deliver SIGPIPE to current thread, but returns >> actually bytes written. > And this sounds wrong. I think that fixing the code for pipes would also > semi-magically makes this correct.