From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M3IJ6-0006gL-6g
	for qemu-devel@nongnu.org; Sun, 10 May 2009 19:19:44 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M3IJ0-0006g0-Ql
	for qemu-devel@nongnu.org; Sun, 10 May 2009 19:19:42 -0400
Received: from [199.232.76.173] (port=53777 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M3IJ0-0006fx-Jq
	for qemu-devel@nongnu.org; Sun, 10 May 2009 19:19:38 -0400
Received: from mail-gx0-f176.google.com ([209.85.217.176]:65088)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1M3IJ0-0002ce-Bz
	for qemu-devel@nongnu.org; Sun, 10 May 2009 19:19:38 -0400
Received: by gxk24 with SMTP id 24so7073272gxk.10
	for <qemu-devel@nongnu.org>; Sun, 10 May 2009 16:19:37 -0700 (PDT)
Message-ID: <4A076106.1010100@codemonkey.ws>
Date: Sun, 10 May 2009 18:19:34 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] suppress 'warn_unused_result' warning
References: <ee84806e0905101215gf32927j1b510a0084038e20@mail.gmail.com>
	<20090510221500.GA27879@miranda.arrow>
In-Reply-To: <20090510221500.GA27879@miranda.arrow>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stuart Brady <sdbrady@ntlworld.com>
Cc: qemu-devel@nongnu.org

Stuart Brady wrote:
> 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?
>
> 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?
>   

EINTR is rather unfortunate.  A lot of libraries don't handle it well, 
for instance.

One the IO thread stabilizes and we can enable it by default, we'll be 
able to eliminate signaling in the IO thread and thereby eliminate all 
of the potentially buggy EINTR handling.

I think that's the best path forward.

NB we would still send the TCG thread signals to break it out of 
execution but the TCG thread should not generally be doing system calls.


Regards,

Anthony Liguori