From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48822 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwx53-0003Hb-DO for qemu-devel@nongnu.org; Tue, 08 Mar 2011 08:36:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwx52-0008M2-Ah for qemu-devel@nongnu.org; Tue, 08 Mar 2011 08:36:05 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:34324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwx52-0008LP-82 for qemu-devel@nongnu.org; Tue, 08 Mar 2011 08:36:04 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p28DGiVb011150 for ; Tue, 8 Mar 2011 08:16:44 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id B807A38C803C for ; Tue, 8 Mar 2011 08:35:54 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p28DZuTg381874 for ; Tue, 8 Mar 2011 08:35:56 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p28DZuIo011194 for ; Tue, 8 Mar 2011 10:35:56 -0300 Message-ID: <4D7630BA.4010609@us.ibm.com> Date: Tue, 08 Mar 2011 07:35:54 -0600 From: Anthony Liguori 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> <4D760F2B.7030004@redhat.com> In-Reply-To: <4D760F2B.7030004@redhat.com> 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: Avi Kivity Cc: Stefan Hajnoczi , Luiz Capitulino , qemu-devel@nongnu.org, Markus Armbruster , Adam Litke On 03/08/2011 05:12 AM, Avi Kivity wrote: > 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). I've implemented them (for virt-agent) and I'll have it in v2 of round 1. I use callbacks. If a function is marked to be async, it generates a signature like: typedef void (GuestViewFileCompletionFunc)(void *qmp__opaque, const char * qmp__retval, Error *qmp__err); void qmp_guest_view_file(const char * filename, Error **err, GuestViewFileCompletionFunc *qmp__cc, void *qmp__opaque); The handler just needs to squirrel away qmp__cc and qmp__opaque and call it whenever the command completes. >> >> 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. Yup, this is pretty much what I'm now doing. >> 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? Yeah, all of the guest commands need to be asynchronous so we definitely need to support it. Regards, Anthony Liguori