From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPcl5-0008Fj-T7 for qemu-devel@nongnu.org; Wed, 12 Aug 2015 16:36:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPcl1-0004pL-ME for qemu-devel@nongnu.org; Wed, 12 Aug 2015 16:36:23 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:37245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPcl1-0004p3-F2 for qemu-devel@nongnu.org; Wed, 12 Aug 2015 16:36:19 -0400 Date: Wed, 12 Aug 2015 16:36:16 -0400 (EDT) From: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Message-ID: <761108243.8538357.1439411776597.JavaMail.zimbra@redhat.com> In-Reply-To: <55CBA5C1.1010401@redhat.com> References: <1439408763-12785-1-git-send-email-marcandre.lureau@redhat.com> <1439408763-12785-2-git-send-email-marcandre.lureau@redhat.com> <55CBA5C1.1010401@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 1/3] monitor: split MonitorQAPIEventState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: marcandre lureau , qemu-devel@nongnu.org Hi ----- Original Message ----- > On 08/12/15 21:46, marcandre.lureau@redhat.com wrote: > > From: Marc-Andr=C3=A9 Lureau > >=20 > > Create a seperate pending event structure MonitorQAPIEventPending. > > Use a MonitorQAPIEventDelay callback to handle the delaying. This > > allows other implementations of throttling. > >=20 > > Signed-off-by: Marc-Andr=C3=A9 Lureau > > --- > > monitor.c | 124 > > +++++++++++++++++++++++++++++++++++++---------------------- > > trace-events | 2 +- > > 2 files changed, 79 insertions(+), 47 deletions(-) >=20 > 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. >=20 > 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. >=20 > 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 perio= d, 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 wa= y 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".=20 cheers