Hi ----- Original Message ----- > On 08/12/15 21:46, [email protected] wrote: > > From: Marc-André Lureau <[email protected]> > > > > 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 <[email protected]> > > --- > > 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
