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

[Eduardo Habkost]

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.

-- 
Eduardo