From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4pTJ-0002eg-Dq for qemu-devel@nongnu.org; Tue, 06 Mar 2012 03:10:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4pTD-0002GR-7v for qemu-devel@nongnu.org; Tue, 06 Mar 2012 03:10:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4pTC-0002Fd-Vf for qemu-devel@nongnu.org; Tue, 06 Mar 2012 03:10:07 -0500 Message-ID: <4F55C658.9090403@redhat.com> Date: Tue, 06 Mar 2012 09:10:00 +0100 From: Gerd Hoffmann MIME-Version: 1.0 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> <20120306075643.GC14238@garlic> In-Reply-To: <20120306075643.GC14238@garlic> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Avi Kivity , qemu-devel@nongnu.org, Anthony Liguori , Luiz Capitulino On 03/06/12 08:56, Alon Levy wrote: > 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 Hmm? spice client can ask for a screendump via libvirt? /me looks completely puzzled. cheers, Gerd