qemu-devel
[Top][All Lists]
Advanced

[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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
Date: Mon, 05 Mar 2012 20:17:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

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.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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