From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxKEC-0005Cj-2V for qemu-devel@nongnu.org; Thu, 01 Apr 2010 09:14:32 -0400 Received: from [140.186.70.92] (port=49977 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxKEA-0005Ba-NQ for qemu-devel@nongnu.org; Thu, 01 Apr 2010 09:14:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxKE9-0005G4-7n for qemu-devel@nongnu.org; Thu, 01 Apr 2010 09:14:30 -0400 Received: from mx20.gnu.org ([199.232.41.8]:39910) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxKE9-0005G0-4S for qemu-devel@nongnu.org; Thu, 01 Apr 2010 09:14:29 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NxKE8-0001dl-7y for qemu-devel@nongnu.org; Thu, 01 Apr 2010 09:14:28 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU Date: Thu, 1 Apr 2010 13:14:24 +0000 References: <1269535420-31206-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <4BB10E30.70908@redhat.com> <4BB110B3.8040300@linux.vnet.ibm.com> In-Reply-To: <4BB110B3.8040300@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004011414.24879.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: ericvh@gmail.com, Anthony Liguori , jvrao , Avi Kivity , "Aneesh Kumar K.V" >>> 1) state machines with a thread pool to make blocking functions >>> asynchronous (what we have today) >>> >>> 2) co-operative threading >>> >>> 3) pre-emptive threading > > On a philosophical note, threads may be easier to model complex > > hardware that includes a processor, for example our scsi card (and how > > about using tcg as a jit to boost it :) > > Yeah, it's hard to argue that script evaluation shouldn't be done in a > thread. But that doesn't prevent me from being very cautious about how > and where we use threading :-) I agree that making script execution asynchronous is a good thing, however I'm not convinced that (3) is the best way to do this. It's certainly the most flexible model, however it also places responsibility for locking/correctness on the device developer. A more limited scheme (e.g. asynchronous callbacks) can actually be significant advantage. By forcing the developer to solve the problem in a particular way we significantly reduce the scope for race conditions, and hopefully restrict all locking concerns to common code/APIs. Paul [1] This issue may come from accidental misuse of terminology, but it's an important distinction.