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

[Alon Levy]

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 <address@hidden> 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
> 
>