Support for increasing/decreasing limits on the fly about ratelimit

[bcap]

Right now to have something like this that doesnt allow bursts to pass by, there is this poor man's option (and likely also naive) which is something managed outside the lib:

1. have a single rate limiter for normal ops
2. when an increase/decrease is requested, create a second rate limiter with the new value. We enter "swapping mode"
3. Take now takes from both rate limiters in either serial or parallel fashion (not sure about which has better correctness here yet)
4. When the window of the first (old) rate limiter is expired, remove it (we need to track windows here)
5. We are back at having a single rate limiter
6. The swapping mode is done, allowing more calls to increase/decrease again. Any calls to increase/decrease that were done while we were in swapping mode either got rejected, waiting (blocked) or executed later (async)

[rabbbit]

Generally seems plausible, but as I commented in the other task, I don't expect to have bandwidth to work on this soon.

However, reading your use-case, I'm not sure if updating limits on the fly would make sense - it seems like you want some kind of burst++ mode, rather than external limits?

Note to self: #69 was asking for the same feature.

[shmilyoo]

you can wrap it, and use a block channel to stop the rate limit

func (rl *RateLimit) Take() time.Time {
	<-rl.blockSignal
	return rl.throttle.Take()
}

[bruno-nascimento]

Hi, I know I must be missing something here 😓
Why can't we have something like this to achieve the same goal ?

type Limiter struct {
	limiter ratelimit.Limiter
	mutex   sync.RWMutex
}

func NewLimiter(cfg config) Limiter {
	return Limiter{limiter: ratelimit.New(cfg.LimiterOperations, ratelimit.Per(cfg.LimiterDuration))}
}

func (l *Limiter) Update(ops int, duration time.Duration) {
	l.mutex.Lock()
	defer l.mutex.Unlock()
	l.limiter = ratelimit.New(ops, ratelimit.Per(duration))
}

func (l *Limiter) Take() time.Time {
	l.mutex.RLock()
	defer l.mutex.RUnlock()
	return l.limiter.Take()
}

As far as I could see, we could update the limiter while calling limiter.Take() from different go routines without any issue

time.AfterFunc(time.Second*5, func() {
        limiter.Update(3, time.Second)
})

time.AfterFunc(time.Second*10, func() {
        limiter.Update(20, time.Second)
})

time.AfterFunc(time.Second*15, func() {
        limiter.Update(100, time.Second)
})

[rabbbit]

Sorry, we don't foresee adding this to the library - contrary to your example, replacing the limit on the fly has non-obvious behavior wrt already existing limits and slack. Additionally, the extra lock defeats the purpose of the lock-less implementation we have.

Since, however, as your example shows it is simple enough to wrap this in your own code. We would encourage you to do just that if that fits your requirements.