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. > > -- > error compiling committee.c: too many arguments to function > >
