Re: [Qemu-devel] [RFC 1/3] monitor: split MonitorQAPIEventState

["Marc-André Lureau" <mlureau@redhat.com>]

Hi

----- Original Message -----
> On 08/12/15 21:46, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > 
> > Create a seperate pending event structure MonitorQAPIEventPending.
> > Use a MonitorQAPIEventDelay callback to handle the delaying. This
> > allows other implementations of throttling.
> > 
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> >  monitor.c    | 124
> >  +++++++++++++++++++++++++++++++++++++----------------------
> >  trace-events |   2 +-
> >  2 files changed, 79 insertions(+), 47 deletions(-)
> 
> Assume there has been a long period of silence (no attempts to emit an
> event). Now some client code makes a call to emit the event.
> 
> Will that event be emitted immediately, or will it be delayed to see if
> more are coming? I'd like to understand this aspect first.
> 
> I think the first instance of the event, after the grace period, should
> be emitted immediately, and further instances that quickly follow should
> be suppressed.

This is what qemu already does. The first event is sent immediately, the
later ones may be delayed (but there will be at least one event every period,
if the event is flooded). This patch 1/3 doesn't change the logic, only
it split things to make them a bit more modular.

So the rest of the patches do not change the qemu delay logic, it adds a way to
delay based on (event + "id") instead of just (event). It does that by
adding an additional "id" hashtable for the event type. My hope is
that this apporach could be reused if other field or combinations of fields
are necessary for other events, but for now, it's hardcoded for "id". 

cheers