From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42837 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0yJW-0002AV-VQ for qemu-devel@nongnu.org; Wed, 29 Sep 2010 11:11:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0yJQ-0001rQ-2G for qemu-devel@nongnu.org; Wed, 29 Sep 2010 11:11:22 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:41331) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0yJP-0001q9-RF for qemu-devel@nongnu.org; Wed, 29 Sep 2010 11:11:16 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o8TF96YM006661 for ; Wed, 29 Sep 2010 09:09:06 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8TFB8GI179304 for ; Wed, 29 Sep 2010 09:11:09 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o8TFB80x029040 for ; Wed, 29 Sep 2010 09:11:08 -0600 Message-ID: <4CA3570C.3080000@linux.vnet.ibm.com> Date: Wed, 29 Sep 2010 10:11:08 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 05/18] Monitor: Drop is_async_return() References: <1284668464-15981-1-git-send-email-lcapitulino@redhat.com> <1284668464-15981-6-git-send-email-lcapitulino@redhat.com> <20100929102821.6b80eac4@doriath> In-Reply-To: <20100929102821.6b80eac4@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Markus Armbruster , qemu-devel@nongnu.org On 09/29/2010 08:28 AM, Luiz Capitulino wrote: > On Wed, 29 Sep 2010 13:21:08 +0200 > Markus Armbruster wrote: > > >> Luiz Capitulino writes: >> >> >>> If I understood it correcty, the is_async_return() logic was only >>> used to prevent QMP from issuing duplicated success responses >>> for asynchronous handlers. >>> >>> However, QMP doesn't use do_info() anymore so this is dead logic >>> and (hopefully) can be safely dropped. >>> >> Looks like it. >> >> Does anybody understand this async monitor stuff? >> > I guess I do, but every now and then it surprises me someway. > > >> It's used only for >> "info balloon" and "balloon". It keeps getting in the way. I'm sorely >> tempted to rip it out and reimplement it after we're done refactoring >> the monitor. >> > I've considered doing that, but then I realized that it's actually a good > interface with two serious problems: > > 1. It's half done. A true async interface would provide a way to list and > cancel requests (at the API level and in QMP/HMP) > > 2. It got too complex, and that's so because of the current state of the > Monitor code > > My optimistic side is telling me that both problems can be solved during > the refactoring process: Monitor code will be simplified and the current > async interface could be used as the basis for the internal QMP API (which > should be async-only, but that's another discussion). > I think one of the ugly bits of QMP as a protocol is capabilities negotiation because it implies that QMP has stateful sessions. Capabilities doesn't have to imply a stateful session but some of the things we've discussed in the past would (like event notification masking). When you look at other RPCs like XML-RPC, REST, or even JSON-RPC over HTTP, in order to be used over HTTP it's important that the actual RPC session has no state because HTTP is stateless. The reason this discussion matters is because today we have a Monitor object that all commands operate on and could potentially use to store state. An alternative model would be to do away with the Monitor object used by the commands which means the commands have no way to store session state. The human monitor needs state because it's stateful but it's not clear that we need to do this with QMP. I think the vast majority of the complexity of async is based on the fact that we have a session object and we make the session object globally available. I don't think this is really something we've ever considered with QMP though. Regards, Anthony Liguori Regards, Anthony Liguori