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

[Daniel P. Berrange]

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.

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 :|