From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ6PS-0008ET-NS for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:51:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ6PO-0008Ab-Sf for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:51:38 -0400 Received: from [199.232.76.173] (port=52622 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ6PO-0008AP-Fy for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:51:34 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:16044) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ6PN-0006NS-Us for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:51:34 -0400 Message-ID: <4A40DDE1.7070207@siemens.com> Date: Tue, 23 Jun 2009 15:51:29 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090623012911.16b8c4d5@doriath> <20090623103251.GH6881@redhat.com> <20090623103616.409b716a@doriath> <20090623134851.GC6462@blackpad> In-Reply-To: <20090623134851.GC6462@blackpad> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 , "Daniel P. Berrange" , qemu-devel@nongnu.org, aliguori@us.ibm.com, jan.kiszka@siemens.com, dlaor@redhat.com, avi@redhat.com Eduardo Habkost wrote: > 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. Can't mgmt app and qemu also run on different hosts? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux