From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4pGV-00006t-Qh for qemu-devel@nongnu.org; Tue, 06 Mar 2012 02:57:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4pGN-0008Am-M8 for qemu-devel@nongnu.org; Tue, 06 Mar 2012 02:56:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4pGN-0008Ae-Dn for qemu-devel@nongnu.org; Tue, 06 Mar 2012 02:56:51 -0500 Date: Tue, 6 Mar 2012 09:56:43 +0200 From: Alon Levy Message-ID: <20120306075643.GC14238@garlic> References: <1330956981-5001-1-git-send-email-alevy@redhat.com> <4F54CEA2.10808@codemonkey.ws> <4F54F5F8.70105@redhat.com> <4F54F76B.70403@codemonkey.ws> <20120305143142.1a1a53e2@doriath.home> <20120305180958.GC20937@garlic.tlv.redhat.com> <4F550350.7030703@redhat.com> <4F55BE82.3030205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F55BE82.3030205@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Luiz Capitulino , Avi Kivity , Anthony Liguori , qemu-devel@nongnu.org On Tue, Mar 06, 2012 at 08:36:34AM +0100, Gerd Hoffmann wrote: > Hi, > > >> How would the parallel execution facility be opaque to the implementer? > >> screendump returns, screendump_async needs to pass a closure. You can > >> automatically generate any amount of code, but you can only have a > >> single function implementation with longjmp/coroutine, or having a > >> saparate thread per command but that would mean taking locks for > >> anything not trivial, which avoids the no-change-to-implementation. Is > >> this what you have in mind? > > > > It would not be opaque to the implementer. But it would avoid > > introducing new commands and events, instead we have a unified mechanism > > to signal completion. > > Ok. We have a async mechanism today: .mhandler.cmd_async = ... > > I know it has its problems like no cancelation and is deprecated and > all. But still: how about using it as interim until QAPI-based async > monitor support is ready? We could unbreak qxl screendumps without > having to introduce a new (but temporary!) screendump_async command + > completion event. Actually, I'm not sure this doesn't reintroduce the original problem (which I haven't been able to reproduce): client: screenshot <-> client libvirt <-> host libvirt host libvirt (screendump) <-> qemu monitor -> <- spice server <-> client > > cheers, > Gerd >