From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60734 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PwuqY-0006Uv-FU for qemu-devel@nongnu.org; Tue, 08 Mar 2011 06:12:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PwuqX-0007vn-BZ for qemu-devel@nongnu.org; Tue, 08 Mar 2011 06:12:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PwuqX-0007vj-03 for qemu-devel@nongnu.org; Tue, 08 Mar 2011 06:12:57 -0500 Message-ID: <4D760F2B.7030004@redhat.com> Date: Tue, 08 Mar 2011 13:12:43 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1 References: <1299460984-15849-1-git-send-email-aliguori@us.ibm.com> <4D7500C8.1080101@codemonkey.ws> In-Reply-To: <4D7500C8.1080101@codemonkey.ws> 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: Anthony Liguori Cc: Adam Litke , Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org, Luiz Capitulino , Markus Armbruster On 03/07/2011 05:59 PM, Anthony Liguori wrote: > >> How do async commands work? You mentioned them when talking about >> QAPI but it's not obvious to me that there is any "native" support for >> async commands? > > Async commands are interesting.. Would there be anything in them other than starting each command in its own thread? If it then drops the right locks it can execute in parallel with other commands, if it doesn't, then it's synchronous (and presumably doesn't depend on external or guest events). > > Generating async commands with QAPI is easy. Errors are propagated > now so the callback would just need to take the return value and error > type. It would need to be a special callback type for each function > but that's easy with the code generator. > > Async commands are problematic from the client perspective though. I > think there are two relevant use-cases for client software. There's > the probably most dominant, I don't really care about small pauses > users who are going to be executing the RPCs synchronously either > using libqmp or Python. They may use threading to have some > parallelism but generally, the expectation is going to be that QEMU > doesn't introduce too much delay in processing a given RPC. It's more for intrinsically long-running commands like migration. These can be split into a start-migration and cancel-migration command (and it also helps for querying status, which doesn't follow naturally for an asychronous command). > > OTOH, there are users that will be purely event driven that will treat > every RPC asynchronously. In both cases, it's more or less > all-or-nothing. Having some commands delay for really long periods of > time means that you either force users to treat some commands > specially, or you force all users into an event driven model. > > And of course, if you have async commands, you need to cancel > commands, and then the context is within a single QMP session which > means that you need to figure out what to do if you drop the session > while an async command is executing. For instance, if a management > tool executes the migrate command, and it's implemented as an async > command, if the management tool loses it's connection, should > migration be automatically cancelled? Sounds reasonable. The rules could be: - a command (all commands are async) takes a ref on the monitor context - if the session is dropped, call the current command's cancel callback as a result, a dropped session causes the command to either cancel or complete. > I'm really on the fence about async commands. At the moment, I'm > leaning towards just not every implementing them. Do we have a list of candidates for async commands? -- error compiling committee.c: too many arguments to function