Grokbase › Groups › Go › golang-nuts › January 2015
FAQ
The code is in this section: Simpler Approach that doesn't need channels or
go routines
<https://github.com/golang/go/wiki/RateLimiting#simpler-approach-that-doesnt-need-channels-or-go-routines>

May be I am missing something crucial here, but is there something wrong
with this line:

r.allowance += float64(elapsed) * rate

Unit of `elapsed` is `time.Duration` (which is the same as
`time.Nanosecond`), while rate is per sec (as the comment above the
definition of NewRateLimiter function). When the 2 multiply, it will be
huge. Although it's clamped below, it seems like it's unlimited. I think
the correct one should be:

r.allowance += float64(elapsed) / float64(time.Second) * rate

The code is from Github Wiki and I don't know where to report or even if I
am right, so I have to ask here first. Apologize to readers for any
inconvenience.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Enormouspenguin at Jan 31, 2015 at 4:14 am ⇧
    Nobody care enough to confirm this? I just want to contribute but I lack
    the confidence in my skill. Just a simple "yes, go ahead" or "no, you are
    dead wrong" is ok to me.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tamás Gulácsi at Jan 31, 2015 at 8:01 am ⇧
    Yes, you are right.

    The reason nobody cares is that this approach is simply bad: you can do only busy wait, or explicit time.Sleep - the token bucket (buffered channel) approach is cleaner and provides synchronization and no busy waiting: more concurrency, less CPU.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Christopher Probst at Jan 31, 2015 at 8:39 am ⇧
    I'm using my token package <https://github.com/chrisprobst/token> for rate
    limiting in a huge p2p application. It uses channels and can create
    readers, writers and net.conns.

    Am Freitag, 30. Januar 2015 16:16:00 UTC+1 schrieb enormouspenguin:
    The code is in this section: Simpler Approach that doesn't need channels
    or go routines
    <https://github.com/golang/go/wiki/RateLimiting#simpler-approach-that-doesnt-need-channels-or-go-routines>

    May be I am missing something crucial here, but is there something wrong
    with this line:

    r.allowance += float64(elapsed) * rate

    Unit of `elapsed` is `time.Duration` (which is the same as
    `time.Nanosecond`), while rate is per sec (as the comment above the
    definition of NewRateLimiter function). When the 2 multiply, it will be
    huge. Although it's clamped below, it seems like it's unlimited. I think
    the correct one should be:

    r.allowance += float64(elapsed) / float64(time.Second) * rate

    The code is from Github Wiki and I don't know where to report or even if I
    am right, so I have to ask here first. Apologize to readers for any
    inconvenience.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Enormouspenguin at Jan 31, 2015 at 4:27 pm ⇧

    The reason nobody cares is that this approach is simply bad: you can do
    only busy wait, or explicit time.Sleep - the token bucket (buffered
    channel) approach is cleaner and provides synchronization and no busy
    waiting: more concurrency, less CPU.

    I know that if you simply drop excessive tokens, busy wait is applied and
    no sleep required. But when you need to be notified, some kind of sleep
    must be applied. I think busy wait or explicit sleep is a must, with or
    without the use of (buffered) channel. What do you means by saying that
    it's bad? Do you have a better implementation that you could share because
    I am dying to see it ?

    I'm using my token package <https://github.com/chrisprobst/token> for
    rate limiting in a huge p2p application. It uses channels and can create
    readers, writers and net.conns.
    Thanks for introducing your package. I definitely am going to check it out
    later for ideas on doing large scale Rate Limiting.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tamás Gulácsi at Jan 31, 2015 at 4:47 pm ⇧
    Use channels and select. The runtime knows when a channel send/recv becomes possible, and your goroutine is woken up - no busy wait is needed.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Enormouspenguin at Feb 1, 2015 at 3:10 am ⇧
    Could you give a short example on Go Playground <https://play.golang.org/> because
    I couldn't even imagine it, let alone putting it together like you
    described.
    On Saturday, January 31, 2015 at 11:47:21 PM UTC+7, Tamás Gulácsi wrote:

    Use channels and select. The runtime knows when a channel send/recv
    becomes possible, and your goroutine is woken up - no busy wait is needed.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Enormouspenguin at Feb 1, 2015 at 3:16 am ⇧
    On second thought, are we on the same page here? I think you means your
    implementation is capable of Rate Limiting without both busy wait and
    explicit sleep. Is that right? Because basically, I know how channel and
    SELECT statement works. And what I want is not an example about how to use
    it but about Rate Limiting algorithm.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 30, '15 at 3:16p
activeFeb 1, '15 at 3:16a
posts8
users3
websitegolang.org

3 users in discussion

Enormouspenguin: 5 posts Tamás Gulácsi: 2 posts Christopher Probst: 1 post

Content

People

Support

Translate

site design / logo © 2021 Grokbase