From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3Kl6-0003sA-KE for qemu-devel@nongnu.org; Sun, 10 May 2009 21:56:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3Kl2-0003oC-5D for qemu-devel@nongnu.org; Sun, 10 May 2009 21:56:48 -0400 Received: from [199.232.76.173] (port=47522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3Kl1-0003nr-TQ for qemu-devel@nongnu.org; Sun, 10 May 2009 21:56:43 -0400 Received: from bsdimp.com ([199.45.160.85]:54186 helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M3Kl1-0007MF-8l for qemu-devel@nongnu.org; Sun, 10 May 2009 21:56:43 -0400 Date: Sun, 10 May 2009 19:53:35 -0600 (MDT) Message-Id: <20090510.195335.-1303462317.imp@bsdimp.com> Subject: Re: [Qemu-devel] [PATCH] suppress 'warn_unused_result' warning From: "M. Warner Losh" In-Reply-To: <20090510221500.GA27879@miranda.arrow> References: <20090510221500.GA27879@miranda.arrow> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: sdbrady@ntlworld.com Cc: qemu-devel@nongnu.org In message: <20090510221500.GA27879@miranda.arrow> Stuart Brady writes: : On Mon, May 11, 2009 at 03:15:11AM +0800, Chih-Min Chao wrote: : > The patch add error handling to functions with 'warn_unused_result' return : > value such as write, read, ftruncate, and realpath. : : I'm slightly concerned -- read(), write() and ftruncate() can fail with : EINTR if a signal is received at an unfortunate time, can't they? It depends on how the signal mask for the system call is setup. : Do we mitigate this for the most part, somehow? : : Do kernels try to avoid this behaviour? If so, under what circumstances : might EINTR still be returned? When a signal is received and you are waiting for data, you get EINTR. If there's data available, then I believe the behavior is to return that data and not EINTR. That's the way Unix works. : Is it acceptable to have a wrapper around these functions that retries : if the call fails with EINTR? : : I would guess that for the most part, getting EINTR back is pretty rare, : as there's an awful lot of code (in QEMU and in other projects) that : doesn't check for it. It is very rare... : BTW, is it be possible for the write in qemu_event_increment() to : io_thread_fd to fail with EAGAIN? If so, aborting with perror() : probably isn't right. Warner