[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infras
From: |
Jan Kiszka |
Subject: |
[Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure |
Date: |
Tue, 23 Jun 2009 15:51:29 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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" <address@hidden> 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 <address@hidden>.
>>>>
>>>> Signed-off-by: Luiz Capitulino <address@hidden>
>>>> ---
>>>> 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