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 >
