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!
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With