Hi all,
I am building a small Go CLI, shotcheck, that checks every PNG in a folder against the exact size the App Store slot wants. A pool of workers (8 by default) reads names from jobs, checks them and sends a Result into an unbuffered results channel. collect in main reads them, and on the first bad one calls cancel() and returns an error. Visible behaviour is right: it prints checked 11 of 40, then FAIL with the file name, exit code 1.
My problem is the -debug flag. After a failure I print runtime.NumGoroutine() after a short sleep and expected 1. I get 10 with 8 workers, and 6 with -workers 4, so always workers + 2. A longer sleep (2s, then 5s) changes nothing. I am writing this from memory of my last run, as I can't run Go on this machine right now.
The producer goroutine does stop and jobs is closed, so I don't understand why the canceled context did not stop the rest. I tried moving cancel() around, no change. I suspect the WaitGroup, or defer cancel() running too late.
In the CLI it is harmless because the process exits. But I want this pool inside a long-running CI helper, and there I think these goroutines would pile up on every failed run and slow the machine a lot.
The worker part:
for i := 0; i < n; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for path := range jobs {
r := checkShot(path)
results <- r
}
}()
}
go func() {
wg.Wait()
close(results)
}()
Is it possible that I am missing something simple here? Thanks for reading))