没有通道的 golang errgroup 示例

Question

I saw the example of errgroup in godoc, and it makes me confused that it simply assigns the result to global results instead of using channels in each search routines. Heres the code:

Google := func(ctx context.Context, query string) ([]Result, error) {
g, ctx := errgroup.WithContext(ctx)

searches := []Search{Web, Image, Video}
results := make([]Result, len(searches))
for i, search := range searches {
    i, search := i, search // https://golang.org/doc/faq#closures_and_goroutines
    g.Go(func() error {
        result, err := search(ctx, query)
        if err == nil {
            results[i] = result
        }
        return err
    })
}
if err := g.Wait(); err != nil {
    return nil, err
}
return results, nil

}

I'm not sure is there any reason or implied rules guarantees it is correct? THX

Answer 1

The intent here is to make searches and results congruent. The result for the Web search is always at results[0] , the result for the Image search always at results[1] , etc. It also makes for a simpler example, because there is no need for an additional goroutine that consumes a channel.

If the goroutines would send their results into a channel, the result order would be unpredictable. If predictable result order is not a property you care about feel free to use a channel.

Answer 2

There is secret sauce in this code that creates siloing:

results := make([]Result, len(searches))
           ^^^^           ^^^^^^^^^^^^^

for i, search := ... {
    i, search := i, search
          ^^^^^^^^^^
    g.Go {
        results[i] = result
        ^^^^^^^^^^
    }

We know how big the result set is going to be, so we pre-allocate all the slots before starting any goroutines. This eliminates any contention over the slice object itself

make(.., len(searches))
^^^^     ^^^^^^^^^^^^^

We then promote the index number and search property to a closure for each iteration, so there is no contention over the variables being used by the loop/goroutines

    i, search := i, search

And finally, each worker operates on a singular slot in the pre-sized slice:

        results[i] = result

The workers are guaranteed to only perform read operations on the "results" slice to find out where their element is ( results[i] ).

This particular pattern is limiting, you can't use the results until all the workers are completed. So ask yourself what you're going to do next when deciding whether to use this or a channels-based pipeline workflow.

results := getSearchResults(searches)
statistics := analyzeResults(results)
for stats := range statistics {
    our.Write("{%s}\n", stats.String())
}

If the analysis of a given result is independent of any other, this is a good candidate for a channel-based workflow.

But if the analysis depends on order, or has different results depending on each other then you may not have any choice but to serialize the flow.