Reputation: 459
I new to golang
and I am reading the example from the book gopl.
There is an example of making thumbnails in parallel:
func makeThumbnails6(filenames <-chan string) int64 {
sizes := make(chan int64)
var wg sync.WaitGroup // number of working goroutines
for f := range filenames {
wg.Add(1)
// worker
go func(f string) {
defer wg.Done()
thumb, err := thumbnail.ImageFile(f)
if err != nil {
log.Println(err)
return
}
info, _ := os.Stat(thumb) // OK to ignore error
sizes <- info.Size()
}(f)
}
// closer
go func() {
wg.Wait()
close(sizes)
}()
var total int64
for size := range sizes {
total += size
}
return total
}
My doubt is that will it be possible that the closer passes the wg.Wait()
before all files are processed?
E.g if work1
finishes its job and decreases wg
to zero, then some magical scheduling happens and close
get the time to run and close the channel?
Any help is appreciated!
Upvotes: 3
Views: 1025
Reputation: 6749
wg.Wait
won't return until all the worker goroutines are done. When wg.Wait
is called in the closer goroutine, you've already called wg.Add(1)
once for each worker goroutine, so wg.Wait
won't return until wg.Done
has been called the same number of times, and that happens when the goroutine function returns. Therefore, the closer goroutine won't call close
until all the worker goroutines have finished what they're doing.
As you said, it is theoretically possible that wg
's counter may reach 0 while still in the loop that creates the workers, but once the loop finishes, the counter will only be 0 once all the goroutines have finished. Since you aren't starting the closer goroutine until the loop completes, there's no danger of wg.Wait
returning before all the workers are done.
Upvotes: 4