Fix bug #179

[eapache]

Almost certainly the same as reported at #199 (comment)

Go's closure semantics are really annoying - simply stop spawning goroutines
with the wrong arguments.

Add a test (heavily based on https://gist.github.com/ORBAT/d0adcd790dff34b37b04)
to ensure this behaviour doesn't regress.

Huge thanks to Tom Eklöf for getting me all the logs etc. needed to track this
down.

@wvanbergen @ORBAT

[wvanbergen]

ouch.

[cdmicacc]

This isn't anything to do with Go's closure semantics. It's simply a misunderstanding about what's going on in a for x := ....

The buggy code can be distilled down to this:

    list := []int{1, 2, 3, 4}
    for x := range list {
        go func() {
            fmt.Printf("x = %d\n", x)
        }()
    }

But you can rewrite that as

    list := []int{1, 2, 3, 4}
    var x int
    for x = range list {
        go func() {
            fmt.Printf("x = %d\n", x)
        }()
    }

In this latter form it's a lot easier to see that what you're closing over with x is actually a single spot in memory whose value is being reassigned on each loop iteration. There is no magic in for x:= range that allocates a new x on each loop iteration. In that case it makes perfect sense that each goroutine sees the same value.

The fix would really be to copy the value, like so:

    list := []int{1, 2, 3, 4}
    for x := range list {
        go func(x int) {
            fmt.Printf("x = %d\n", x)
        }(x)
    }

Since Go passes by value, that will result in a copy of the current value of x being preserved in the goroutine, rather than x itself.

[eapache]

I consider it part of Go's closure semantics that it closes by reference and not by value.