On Mon, 5 Mar 2012 20:58:08 +0200 Alon Levy <al...@redhat.com> wrote:
> On Mon, Mar 05, 2012 at 08:17:52PM +0200, Avi Kivity wrote: > > On 03/05/2012 08:09 PM, Alon Levy wrote: > > > On Mon, Mar 05, 2012 at 02:31:42PM -0300, Luiz Capitulino wrote: > > > > On Mon, 05 Mar 2012 11:27:07 -0600 > > > > Anthony Liguori <anth...@codemonkey.ws> wrote: > > > > > > > > > On 03/05/2012 11:20 AM, Avi Kivity wrote: > > > > > > On 03/05/2012 04:33 PM, Anthony Liguori wrote: > > > > > >> > > > > > >> > > > > > >> async in QEMU doesn't mean "generate a QMP event when you're done". > > > > > >> It should mean execute this closure when you finish (function > > > > > >> pointer > > > > > >> + opaque). > > > > > >> > > > > > >> The QMP event should be dispatched from the closure such that the > > > > > >> screendump code doesn't have to have a direct dependency on QMP. > > > > > >> > > > > > > > > > > > > What about using the parallel execution facility of qmp? It's > > > > > > silly to > > > > > > duplicate every command X with X-async and X-COMPLETED. > > > > > > 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. > > Yeah, that sounds good. Let's have that for 6.4. That's too far away, qemu will have be re-written a dozen of times when we get there. But if you meant 1.2, yes, I hope to have async support for 1.2. But I must admit that I'm having some trouble delivering things on time...