Eric Blake <ebl...@redhat.com> writes:
> On 09/25/2015 08:00 AM, Markus Armbruster wrote:
>> In preparation of turning monitor_qapi_event_state[] into a hash table
>> for finer grained throttling.
>>
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> ---
>> monitor.c | 79
>> ++++++++++++++++++++++++++++++---------------------------------
>> 1 file changed, 38 insertions(+), 41 deletions(-)
>>
>
>> -/*
>> - * @event: the event ID to be limited
>> - * @rate: the rate limit in milliseconds
>> - *
>> - * Sets a rate limit on a particular event, so no
>> - * more than 1 event will be emitted within @rate
>> - * milliseconds
>> - */
>> -static void
>> -monitor_qapi_event_throttle(QAPIEvent event, int64_t rate)
>> -{
>
> At one point, I think we were considering having the rate be
> user-tunable through a qom property, in which case this function is
> still nicer than a monitor_qapi_event_conf[] fixed-rate table. But
> since I don't think we ever used it, I'm fine with dropping the
> complexity and living with a constant rate.
I'm no friend on complicating stuff now to hopefully facilitate things
we might want to do some day, but don't really understand now.
Say we provide a way for the user to configure the rate. Say you
accidentally set the rate to a month, and now want to fix your blunder
by setting it to a minute. If an event has already arrived, the timer
is currently set to expire next month, and your fixed rate will take
effect then.
My point is configuring the rate could be more complicated than storing
the new rate, and keeping monitor_qapi_event_throttle() around won't
make the job materially easier.
> Reviewed-by: Eric Blake <ebl...@redhat.com>
Thanks!
