From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrfUL-0001hn-3r for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:39:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrfUF-0001f7-AB for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:39:16 -0400 Received: from [199.232.76.173] (port=54669 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrfUF-0001f1-3C for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:39:11 -0400 Received: from mx20.gnu.org ([199.232.41.8]:28769) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrfUE-0002vS-PH for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:39:10 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrfUD-0002QR-8B for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:39:09 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command Date: Wed, 8 Apr 2009 21:39:05 +0000 References: <1239200204-4934-1-git-send-email-aliguori@us.ibm.com> <1239222488.21926.39.camel@slate.austin.ibm.com> <49DD13CA.5050209@codemonkey.ws> In-Reply-To: <49DD13CA.5050209@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904082239.06857.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: libvir-list@redhat.com, Jan Kiszka , Hollis Blanchard , Gerd Hoffmann > It has to be some finite amount. You're right, it's arbitrary, but so > is every other memory limitation we have in QEMU. You could make it > user configurable but that's just punting the problem. > > You have to do some level of buffering. It's unavoidable. If you > aren't buffering at the event level, you buffer at the socket level, etc. No you don't. If you use event flags rather than discrete events then you don't need to buffer at all. You just need to be able to store the state of each type of event you're going to raise, which should be a bounded set. This has its own set of issues - typically race conditions or "lost" events if the client (libvirt) code isn't written carefully, and means you can't attach information with an event, only indicate that something happened. However if the correct model is used (event driven polling rather than purely event driven) this shouldn't be problem. Paul