On Sat, May 20, 2023 at 1:23 AM Tobias Klausmann
<klaus...@schwarzvogel.de> wrote:
>
> What I wonder about is the collection stage: the assumption that there
> will be exactly as many results as inputs seems brittle, and the only
> real way to handle errors is to put them into the result struct and
> examining them later.
>
> I also usually prefer handling workers with a `waitgroup`, but that only
> really works if there is no return channel to handle, either because
> the workers do the output/final processing, or because results are
> written to a global. The former is not always possible, and the latter
> is ugly.
>
> There is also the option of just making the result channel big enough
> to hold all results, but that seems a bit ugly as well.
>
> So what's the most idiomatic way of doing this?
The pattern I tend to prefer is
rc := make(chan result, numprocs)
var wg sync.WaitGroup
for i := 0; i < numprocs; i++ {
wg.Add(1)
go func() {
defer wg.Done()
sendResults(rc)
}()
}
go func() {
wg.Wait()
close(rc)
}()
This ensures that the channel is closed when all the results are sent.
Then you can collect the results using one or more goroutines with
"for result := range rc".
Note that for this kind of pattern it's usually a good idea to use a
buffered channel to hold the results, to avoid tight synchronization
between the senders and the processors. Of course sometimes you want
that tight synchronization, but usually you don't. The exact size of
the buffer doesn't matter too much.
You may also want to watch Bryan's talk at
https://www.youtube.com/watch?v=5zXAHh5tJqQ .
Ian
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWNmk5q8pWJ8PJGvwXrqvvF19PPGupBnKtqzw-68jpS1A%40mail.gmail.com.
