From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrpXq-00074I-Lz for qemu-devel@nongnu.org; Thu, 09 Apr 2009 04:23:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrpXl-00073s-Kj for qemu-devel@nongnu.org; Thu, 09 Apr 2009 04:23:33 -0400 Received: from [199.232.76.173] (port=56238 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrpXl-00073p-Eg for qemu-devel@nongnu.org; Thu, 09 Apr 2009 04:23:29 -0400 Received: from mx2.redhat.com ([66.187.237.31]:33882) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrpXk-0002Qo-VL for qemu-devel@nongnu.org; Thu, 09 Apr 2009 04:23:29 -0400 Message-ID: <49DDB0A5.80805@redhat.com> Date: Thu, 09 Apr 2009 11:24:05 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command References: <1239200204-4934-1-git-send-email-aliguori@us.ibm.com> <1239222488.21926.39.camel@slate.austin.ibm.com> <49DD13CA.5050209@codemonkey.ws> <200904082239.06857.paul@codesourcery.com> In-Reply-To: <200904082239.06857.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 , Gerd Hoffmann , Hollis Blanchard Paul Brook wrote: > 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. > I agree. Every event notification should be readable with an info command. The best way to enforce it is to have the event just say 'something changed' and force the management app to issue an info command to find out what exactly. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.