On Fri, Jul 19, 2024 at 1:52 PM 'James Lees' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> Hi there,
> I've never posted here, so apologies if I'm breaching any etiquette, but the
> contribution guide suggests posting here before creating an issue so I
> thought I'd try.
>
> I was debugging an issue recently and saw some strange behaviour in the
> x/time/rate package.
>
> The behaviour is exhibited in the following test
>
> func TestRateIssue(t *testing.T) {
> l := NewLimiter(0, 1)
> fmt.Println(l.Allow()) // should be true
> fmt.Println(l.Allow()) // should be false
>
> l.SetLimit(10)
>
> time.Sleep(1 * time.Second)
> fmt.Println(l.Allow()) // should be true but is false.
> }
>
> This code seems very strange to me. If the burst is 1, decrementing it here
> means that the limiter becomes unusable even if the limit is subsequently
> increased.
>
> This code appeared here but the conversation doesn't really reflect the code:
> the comment says:
>
> > The opposite in fact needs to happen: lim.tokens must be reduced by the n
> > consumed tokens?
>
> Which makes sense to me, but I'm not sure how we ended up decrementing the
> burst. To me the solution to the reported problem (limiters not actually
> being full) would be to set lim.tokens on the constructor, but I haven't
> thought about that too deeply.
>
> I'm happy to propose a change/create an issue but hopefully you folks can
> help me understand whether I'm missing something obvious!
I agree that this seems wrong. Want to open a bug report or send a patch?
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcULD4D_SV_HQ9pkwm1a3UKze%3D4i1rPQ0yBbq0Lkg5pBDA%40mail.gmail.com.
