From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxMLt-0002uT-Hh for qemu-devel@nongnu.org; Thu, 01 Apr 2010 11:30:37 -0400 Received: from [140.186.70.92] (port=41575 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxMLs-0002u8-5f for qemu-devel@nongnu.org; Thu, 01 Apr 2010 11:30:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxMLq-0004Dm-B2 for qemu-devel@nongnu.org; Thu, 01 Apr 2010 11:30:35 -0400 Received: from mx20.gnu.org ([199.232.41.8]:40802) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxMLq-0004Df-7W for qemu-devel@nongnu.org; Thu, 01 Apr 2010 11:30:34 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NxMLp-0003pB-KH for qemu-devel@nongnu.org; Thu, 01 Apr 2010 11:30:33 -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 15:30:29 +0000 References: <1269535420-31206-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <201004011414.24879.paul@codesourcery.com> <4BB4AEFD.4040109@redhat.com> In-Reply-To: <4BB4AEFD.4040109@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004011630.30164.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" > 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. In practice I don't think pre-emtive multithreading actually solves all that many problems. If a script enters an indefinite loop then you want to be terminating or throttling it anyway. The difference is whether you yield/return or drop locks and performing a blocking operation. I suppose what I'm getting at is the difference between explicit multithreading and event based programming. In the latter case I believe it's much easier to have individual devices use a sequential model, but have the whole system be concurrent. > > [1] This issue may come from accidental misuse of terminology, but it's > > an important distinction. > > Missing reference to footnote. I was going to comment on the difference between re-entrancy and concurrency, but decided against it. Paul