From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPdWj-0002cQ-EV for qemu-devel@nongnu.org; Wed, 12 Aug 2015 17:25:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPdWe-0004vy-9k for qemu-devel@nongnu.org; Wed, 12 Aug 2015 17:25:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPdWd-0004vn-QU for qemu-devel@nongnu.org; Wed, 12 Aug 2015 17:25:32 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8528998C32 for ; Wed, 12 Aug 2015 21:25:30 +0000 (UTC) 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> From: Eric Blake Message-ID: <55CBB9C4.8000201@redhat.com> Date: Wed, 12 Aug 2015 15:25:24 -0600 MIME-Version: 1.0 In-Reply-To: <55CBA5C1.1010401@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OM4WCeQWB967vu7e2sdiDMCTFPh0AhqH9" 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 , marcandre.lureau@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OM4WCeQWB967vu7e2sdiDMCTFPh0AhqH9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/12/2015 02:00 PM, Laszlo Ersek wrote: > 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 shoul= d > be suppressed. That has always been the goal of event throttling: when a new event arrives and the timer is not running, emit it right away and start the timer. If another event arrives while the timer has not expired, save it. If multiple events arrive during the timer, the last one received overwrites any others. Then, when the timer expires, either there is a saved event (one or more events arrived during the throttling window), so we send it and restart another throttling window, or there was no event pending so the line is quiet and the next event can send right away. Thus, management will get notification as soon as possible that events are starting to happen after a period of quiet, but will then not be spammed any faster than once per throttle period (once per second) with additional events. When additional events are sent, they are always the most accurate state of the system at the time the event was queued, but intermediate events may have been lost. Furthermore, unless the events have not been happening, the throttling of the event means the management might not see the event until nearly a second late, although the timestamp associated with the event should still be accurate to the time it was queued up, not finally sent. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OM4WCeQWB967vu7e2sdiDMCTFPh0AhqH9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVy7nEAAoJEKeha0olJ0NqO1wH/1mMxFJ5z89oU7767Ly6i1AC nWs1oeUoa+T48EAklcBmaw4QO//exphxAiHFcgoIvbmet9+tEE6S5a4qN6CYoX+y zhHf5xuYOA3mEiWub3MX37bCg/asOxSKw47SChHggrowCDZSeERnrBaDjo6th8az NJkUN9nkcNWK6Ybxnm6lzfBoR83vD4sCQEpn5aDIhok6orgYtl+47Lvj8xjQ8bJE J1I3okjTQx8rGk6RiTNKuRLfWN2lQGptpeVw3r4IYMfZ2vVPdO4kRBi12ZXwdofF gQbZ1FvrcGrASiyVWiABt3GZVjKQDH7uJYxwG502qwuuEDCCl5SD0knXlFjBJIQ= =zIWx -----END PGP SIGNATURE----- --OM4WCeQWB967vu7e2sdiDMCTFPh0AhqH9--