From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:57190)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1S4owt-0003X4-Ki
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 02:36:44 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1S4owr-0004Ih-Mg
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 02:36:43 -0500
Received: from mx1.redhat.com ([209.132.183.28]:43321)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1S4owr-0004IH-Df
	for qemu-devel@nongnu.org; Tue, 06 Mar 2012 02:36:41 -0500
Message-ID: <4F55BE82.3030205@redhat.com>
Date: Tue, 06 Mar 2012 08:36:34 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1330956981-5001-1-git-send-email-alevy@redhat.com>
	<4F54CEA2.10808@codemonkey.ws> <4F54F5F8.70105@redhat.com>
	<4F54F76B.70403@codemonkey.ws>
	<20120305143142.1a1a53e2@doriath.home>
	<20120305180958.GC20937@garlic.tlv.redhat.com>
	<4F550350.7030703@redhat.com>
In-Reply-To: <4F550350.7030703@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>, Luiz Capitulino <lcapitulino@redhat.com>

  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.

cheers,
  Gerd