From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MXzKz-00085T-Ah
	for qemu-devel@nongnu.org; Mon, 03 Aug 2009 11:20:33 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MXzKu-00081H-0C
	for qemu-devel@nongnu.org; Mon, 03 Aug 2009 11:20:32 -0400
Received: from [199.232.76.173] (port=41682 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MXzKt-000811-HV
	for qemu-devel@nongnu.org; Mon, 03 Aug 2009 11:20:27 -0400
Received: from verein.lst.de ([213.95.11.210]:52841)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MXzKt-0002An-2J
	for qemu-devel@nongnu.org; Mon, 03 Aug 2009 11:20:27 -0400
Date: Mon, 3 Aug 2009 17:20:21 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH] RFC: Add new block driver for the VDI format
Message-ID: <20090803152021.GB15109@lst.de>
References: <4A4E5AFC.4020206@mail.berlios.de>
	<4A51FE07.2040307@codemonkey.ws> <4A75A242.9020005@redhat.com>
	<4A764AAA.1030509@codemonkey.ws> <4A76E002.2060301@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A76E002.2060301@redhat.com>
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: Avi Kivity <avi@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>, Christoph Hellwig <hch@lst.de>

On Mon, Aug 03, 2009 at 04:02:58PM +0300, Avi Kivity wrote:
> Theoretically anything you can do with threads you can do with async 
> operations but experience has proven that async is much more difficult.  
> Consider the last qcow2 bug.

> Locking _is_ an easier problem than figuring out the state machine.  I 
> can't prove this but there's numerous anecdotal evidence on the subject.

Having worked with state machines and threads I agree.  Unless you have
very good runtime support (which I think is almost impossible in C) it's
extremly hard and error prone to do state machines that track every
possible blocking point.  Threads and locking are much easier, but they
come with a cost.  With a threaded model like the one in the qemu taw posix
code currently we will context switch for every request, even if it
would not block.

> 
> -- 
> error compiling committee.c: too many arguments to function
---end quoted text---