From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3YBC-0005O3-UL for qemu-devel@nongnu.org; Mon, 11 May 2009 12:16:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3YB7-0005L8-7u for qemu-devel@nongnu.org; Mon, 11 May 2009 12:16:38 -0400 Received: from [199.232.76.173] (port=47795 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3YB6-0005Kr-WB for qemu-devel@nongnu.org; Mon, 11 May 2009 12:16:33 -0400 Received: from qw-out-1920.google.com ([74.125.92.147]:11866) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M3YB6-0006Hw-MT for qemu-devel@nongnu.org; Mon, 11 May 2009 12:16:32 -0400 Received: by qw-out-1920.google.com with SMTP id 4so1531504qwk.4 for ; Mon, 11 May 2009 09:16:32 -0700 (PDT) Message-ID: <4A084F58.7030706@codemonkey.ws> Date: Mon, 11 May 2009 11:16:24 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] suppress 'warn_unused_result' warning References: <20090510221500.GA27879@miranda.arrow> <20090510.195335.-1303462317.imp@bsdimp.com> <20090511154226.GA29818@miranda.arrow> In-Reply-To: <20090511154226.GA29818@miranda.arrow> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stuart Brady Cc: qemu-devel@nongnu.org Stuart Brady wrote: > On Sun, May 10, 2009 at 07:53:35PM -0600, M. Warner Losh wrote: > >> 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. >> > > So if I do a read() from a file over NFS, and there's an awful lot of > latency (and perhaps even connection problems), and the process gets a > signal -- does that mean that the signal will only be delivered once > data is returned? > > If not, then I would really start to wonder whether /all/ code dealing > with read(), write(), etc. should be written to cope with EINTR (and > also partial reads/writes?) regardless of whatever is done with threads > and signal masks, as doing otherwise seems only to be asking for trouble > at some point. (I'd be especially concerned about signals intended for > libraries that are not under the developer's control...) > Any system call can return EINTR just about. It's not just read/write. In general, very few systems handle EINTR completely and QEMU is no exception here. More should because SIGHUP is fairly common but I think that for the most part, it's sufficiently rare that it's not a problem for most projects. Regards, Anthony Liguori