[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async

From: Alon Levy
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
Date: Tue, 6 Mar 2012 09:56:43 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]