From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55226)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1S4qHS-0004D4-Vq
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 04:02:30 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1S4qHJ-0004mX-N6
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 04:02:02 -0500
Received: from mx1.redhat.com ([209.132.183.28]:9538)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1S4qHJ-0004mG-F4
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 04:01:53 -0500
Message-ID: <4F55D277.9000708@redhat.com>
Date: Tue, 06 Mar 2012 10:01:43 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1330936455-23802-1-git-send-email-pbonzini@redhat.com>
	<4F548263.1070905@siemens.com> <4F54CC8A.5010509@redhat.com>
	<4F54CDFE.3030309@redhat.com> <4F54D866.30402@redhat.com>
	<4F54E64C.4050506@redhat.com> <4F54F97D.4080504@redhat.com>
In-Reply-To: <4F54F97D.4080504@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH] fix select(2) race between
	main_loop_wait and qemu_aio_wait
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: anthony@codemonkey.ws, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org, laurent@vivier.eu

Il 05/03/2012 18:35, Avi Kivity ha scritto:
>>> > > The I/O handlers would still use the qemu mutex, no?  we'd just protect
>>> > > the select() (taking the mutex from before releasing the global lock,
>>> > > and reacquiring it afterwards).
>> >
>> > Yes, that could work, but it is _really_ ugly. 
> Yes, it is...
> 

Let's just fix it in NBD then.

Paolo