From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ3JN-0002Zf-Gd for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:33:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ3JI-0002Xo-Oh for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:33:09 -0400 Received: from [199.232.76.173] (port=36090 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ3JI-0002Xh-JT for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:33:04 -0400 Received: from mx1.redhat.com ([66.187.233.31]:51297) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ3JI-00038T-2D for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:33:04 -0400 Date: Tue, 23 Jun 2009 11:32:51 +0100 From: "Daniel P. Berrange" Message-ID: <20090623103251.GH6881@redhat.com> References: <20090623012911.16b8c4d5@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090623012911.16b8c4d5@doriath> Subject: [Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Tue, Jun 23, 2009 at 01:29:11AM -0300, Luiz Capitulino wrote: > It is just an exported function that will be used by other subsystems > to print specific events to the output buffer. > > This is based in ideas by Amit Shah . > > Signed-off-by: Luiz Capitulino > --- > monitor.c | 18 ++++++++++++++++++ > monitor.h | 6 ++++++ > qemu-tool.c | 4 ++++ > 3 files changed, 28 insertions(+), 0 deletions(-) > > diff --git a/monitor.c b/monitor.c > index 462f60b..df58bdd 100644 > --- a/monitor.c > +++ b/monitor.c > @@ -266,6 +266,24 @@ void monitor_printf_data(Monitor *mon, const char *fmt, ...) > va_end(ap); > } > > +/* Asynchronous events main function */ > +void monitor_notify_event(MonitorEvent event) > +{ > + if (!monitor_ctrl_mode(cur_mon)) > + return; > + > + assert(event < EVENT_MAX); > + monitor_puts(cur_mon, "* EVENT "); > + > + switch (event) { > + case EVENT_MAX: > + // Avoid gcc warning, will never get here > + break; > + } > + > + monitor_puts(cur_mon, "\n"); > +} > + If a client is not reading from the monitor channel quickly enough, then would this cause QEMU to block once the FD buffer is full ? A QEMU level buffer might give more leyway, but we don't want to grow unbounded, so ultimately we'll end up having to drop events. At which point you'd want to send an event to the client indicating that the event queue overflowed, so it can take remedial action to re-sync its state. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|