From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3YeC-0005OE-Lh for qemu-devel@nongnu.org; Mon, 11 May 2009 12:46:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3Ye7-0005NC-KN for qemu-devel@nongnu.org; Mon, 11 May 2009 12:46:35 -0400 Received: from [199.232.76.173] (port=51787 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3Ye7-0005N4-7d for qemu-devel@nongnu.org; Mon, 11 May 2009 12:46:31 -0400 Received: from mx1.redhat.com ([66.187.233.31]:52593) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M3Ye5-0004Wg-D4 for qemu-devel@nongnu.org; Mon, 11 May 2009 12:46:29 -0400 Date: Mon, 11 May 2009 17:25:20 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] suppress 'warn_unused_result' warning Message-ID: <20090511162520.GB1579@redhat.com> References: <20090510221500.GA27879@miranda.arrow> <20090510.195335.-1303462317.imp@bsdimp.com> <20090511154226.GA29818@miranda.arrow> <4A084F58.7030706@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A084F58.7030706@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stuart Brady , qemu-devel@nongnu.org On Mon, May 11, 2009 at 11:16:24AM -0500, Anthony Liguori wrote: > 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. For many system calls you can have them auto-restarted after EINTR by using sigaction() with the SA_RESTART flag. IIRC read/write/poll won't support restarts in this way though, because of the problem of partial data read/writes and partial timeouts for poll meaning you can't auto-restart them without app developer help Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|