From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ6Mu-0006MV-Vq for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:49:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ6Mp-0006Hn-Tv for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:49:00 -0400 Received: from [199.232.76.173] (port=52541 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ6Mp-0006HZ-G7 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:48:55 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47056) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ6Mo-0005TM-TS for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:48:55 -0400 Date: Tue, 23 Jun 2009 10:48:51 -0300 From: Eduardo Habkost Message-ID: <20090623134851.GC6462@blackpad> References: <20090623012911.16b8c4d5@doriath> <20090623103251.GH6881@redhat.com> <20090623103616.409b716a@doriath> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090623103616.409b716a@doriath> Subject: [Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Tue, Jun 23, 2009 at 10:36:16AM -0300, Luiz Capitulino wrote: > On Tue, 23 Jun 2009 11:32:51 +0100 > "Daniel P. Berrange" wrote: > > > 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. > > Wouldn't a buffer flush right at the beginning of this function solve this? > At least for QEMU? No, if the messages aren't being consumed fast enough by the other side. If the consumer isn't consuming the messages fast enough, we would need to either drop messages or block on the channel (that's the code code above would do: block on write()). I agree with Avi: if the system is so busy that the client doesn't consume the monitor messages fast enough, we are already screwed. -- Eduardo