3 ms·

Increasing the channel size to 2 is the correct fix. You don't want to read twice because then you would block waiting for both messages. When the channel siz

Increasing the channel size to 2 is the correct fix. You don't want to read twice because then you would block waiting for both messages. When the channel size is two the two inner writing goroutines can succeed on their write to the channel even if nothing reads from it. The channel has three references, the outer receiver, and the two inner senders. The receiver finishes as soon as its able to receive the first message. So what happens is one of the messages is sent and received, the other is sent and just sits in the channel. Then the channel has no more references and is garbage collected, so there's no memory leak. Also goroutines are scheduled onto threads. So these orphaned goroutines that can't complete eat up memory (their call stack + the channel which can't be completed) as well as put pressure on the scheduler. (though the scheduler is efficient and can handle millions of goroutines) That's why it makes sense to refer to this as a memory leak.

geocar 8y ago
> Increasing the channel size to 2 is the correct fix. Sometimes. Sometimes it is not. For a trivial example, a unix-style wait would be done by reading twice. A job queue would be another. It is not, for the reasons specified in the article, which falsely states that the buffer length and the number of goroutines has some relationship (# channels < # goroutines).
- cdoxsey 8y ago
  The channel size needs to match or exceed the number of producing goroutines. Anything less and the some of the goroutines will block attempting to send to a channel with no receiver. The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended. The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me.
  - geocar 8y ago
    > The channel [buffer] size needs to match or exceed the number of producing goroutines This is not true, for the reasons I outlined. > The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended. That may be, but it doesn't change the fact that go programmers that take this advice are creating a kind of cargo-cult around channels and goroutines that will hold them back. > The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me. If all you ever do with channels and goroutines is simulate threads, you're missing out. Erlang programmers might more-easily appreciate this given that they have to go through an incredible contortion to get this feature that go provides for free.
randomdata 8y ago
> Increasing the channel size to 2 is the correct fix. Or is the correct fix to use errgroup[1]? func doSomethingTwice() error { var g errgroup.Group g.Go(func() error { defer fmt.Println("done wth a") return doSomething("a") }) g.Go(func() error { defer fmt.Println("done with b") return doSomething("b") }) return g.Wait() } [1] https://godoc.org/golang.org/x/sync/errgroup https://godoc.org/golang.org/x/sync/errgroup

geocar 8y ago

> Increasing the channel size to 2 is the correct fix. Sometimes. Sometimes it is not. For a trivial example, a unix-style wait would be done by reading twice. A job queue would be another. It is not, for the reasons specified in the article, which falsely states that the buffer length and the number of goroutines has some relationship (# channels < # goroutines).

cdoxsey 8y ago
The channel size needs to match or exceed the number of producing goroutines. Anything less and the some of the goroutines will block attempting to send to a channel with no receiver. The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended. The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me.
- geocar 8y ago
  > The channel [buffer] size needs to match or exceed the number of producing goroutines This is not true, for the reasons I outlined. > The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended. That may be, but it doesn't change the fact that go programmers that take this advice are creating a kind of cargo-cult around channels and goroutines that will hold them back. > The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me. If all you ever do with channels and goroutines is simulate threads, you're missing out. Erlang programmers might more-easily appreciate this given that they have to go through an incredible contortion to get this feature that go provides for free.

randomdata 8y ago

> Increasing the channel size to 2 is the correct fix. Or is the correct fix to use errgroup[1]? func doSomethingTwice() error { var g errgroup.Group g.Go(func() error { defer fmt.Println("done wth a") return doSomething("a") }) g.Go(func() error { defer fmt.Println("done with b") return doSomething("b") }) return g.Wait() } [1] https://godoc.org/golang.org/x/sync/errgroup https://godoc.org/golang.org/x/sync/errgroup