[Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure

[Jan Kiszka <jan.kiszka@siemens.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" <berrange@redhat.com> 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 <amit.shah@redhat.com>.
>>>>
>>>> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
>>>> ---
>>>>  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