From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxLTw-0000Ig-ES for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:34:52 -0400 Received: from [140.186.70.92] (port=54547 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxLTv-0000IY-6h for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:34:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxLTr-0006WA-An for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:34:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31845) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxLTr-0006W4-19 for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:34:47 -0400 Message-ID: <4BB4AEFD.4040109@redhat.com> Date: Thu, 01 Apr 2010 17:34:37 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU References: <1269535420-31206-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <4BB10E30.70908@redhat.com> <4BB110B3.8040300@linux.vnet.ibm.com> <201004011414.24879.paul@codesourcery.com> In-Reply-To: <201004011414.24879.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: ericvh@gmail.com, Anthony Liguori , jvrao , qemu-devel@nongnu.org, "Aneesh Kumar K.V" On 04/01/2010 04:14 PM, Paul Brook wrote: > >>> 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. > Can you elaborate? When would the callbacks be called? When would the callbacks yield back? If the script isn't run to completion (a halt instruction), there isn't really a good answer to these questions. > [1] This issue may come from accidental misuse of terminology, but it's an > important distinction. > Missing reference to footnote. -- error compiling committee.c: too many arguments to function