jpillora / backoff Goto Github PK

https://app.circleci.com/pipelines/github/jpillora/backoff/2/workflows/502480a2-3fdd-4a49-9f97-e45f58b0d63d/jobs/17

I just observed the circle ci is still enabled for this project.

Can this be disabled?

Screenshots

So dep can use it.

Describe the bug
Run time.Sleep(ws.backoff.Duration()) \\ ws.backoff != nil in arm v7 get a runtime error:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x11e34]

goroutine 51 [running]:
runtime/internal/atomic.goXadd64(0x3db8bcc, 0x1, 0x0, 0x3ea8000, 0x3e9a5e8)
	/usr/local/go/src/runtime/internal/atomic/atomic_arm.go:103 +0x1c
github.com/jpillora/backoff.(*Backoff).Duration(0x3db8bcc, 0xf20220, 0x1cbc5c8)
	/go/pkg/mod/github.com/jpillora/[email protected]/backoff.go:30 +0x30

Environment:

• Infrastructure: on raspberry pi (arm32v7)
• version: github.com/jpillora/backoff v1.0.0
• go version: 1.13

Analyze:

• The details of what operating system (specifically that it was 32bit) were key here to figuring this one out!
• Note, this has to be defined first to make sure it is aligned properly for 32bit ARM OS
• From https://golang.org/pkg/sync/atomic/#pkg-note-BUG
• On ARM, 386, and 32-bit MIPS, it is the caller's responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned.

See: #5 (comment)

@DrTall I'm yet to see a use-case where a concurrent backoff timer is required. Do you have a particular case in mind?

Currently in the circle ci i am unable to view the pipeline for this project. Also from what i observed in pr #18 the ci is not running for PR

I propose to use github actions for CI

I love examples of small, focused tools like this. Great work!

I was wondering if it wouldn't make sense to add a MaxTries: property to indicate that the caller should give up and return an error. Here's a strawman example:

b := &backoff.Backoff{
    Max:    5 * time.Minute,
    MaxTries: 100,
}

for {
    conn, err := net.Dial("tcp", "example.com:5309")
    if err != nil {
        if b.AtMaxTries() {
            fmt.Printf("%s, giving up after %s tries.", err, b.MaxTries)
            return errors.New("Connection Failed")
        }
        d := b.Duration()
        fmt.Printf("%s, reconnecting in %s", err, d)
        time.Sleep(d)
        continue
    }
    //connected
    b.Reset()
    conn.Write([]byte("hello world!"))
    // ... Read ... Write ... etc
    conn.Close()
    //disconnected
}

This could also be done by returning err, duration from b.Duration, where an error indicates that the max number of attempts have occurred, but that would muddy the interface for times when there is no maximum.

In my opinion this repo would attract a lot if new contributors if you can add "hacktoberfest" topic to this repository

More info - https://hacktoberfest.com/participation/#pr-mr-details

Hi !

Do you mind if I include the backoff.go file in one of my libraries? Obviously, I'll credit the authors and provide links to the original repo. My library is also MIT licensed.

It's fine if you don't allow that, I'll have to look for another library, but I really love this one because it's so small and easy to understand and just 1 file. I don't want to use a huge, bloated library.

Thank you !

Great library. Could benefit from the use of a LICENSE file in the root of the repo.
https://github.com/blog/1530-choosing-an-open-source-license

When we use the library, if we don't call Reset() forever, numeric overflow is generated

In ForAttempt(), "durf" variable is float64.

durf := minf * math.Pow(factor, attempt)

but, "dur" variable is int64

dur := time.Duration(durf)

so, if the range of "durf" over the range of "dur", "dur" variable is overflowed.

I see tests as a behavior documentation of the method under test. Currently i see tests of the name Test1, Test2,Test3 etc the intent of which is only understood upon reading the test itself.

I propose refactoring the test names to better describe the scenario that is being tested.