I think Matthew is correct about the immediate source of the deadlock - because the defer is placed too late in the body of grepFile(), the deferred decrement of the waitGroup isn't run on an os.Open() error.
I had the same impression as Jan, I think there is a concern here: the condition for closing grepChan could be, when all files have been sent into the channel. Currently, it's when all work is done. The difference is that one pattern is to increment/decrement waitGroup per unit of work, but another one is to increment/decrement just workers. For the latter, the worker decrements when it infers there is no more work to be done, i.e. it reads that grepChan has closed. I think changing the pattern would avoid the deadlock because, then, there's no reason to interact with the waitGroup per file. On Sunday, October 2, 2022 at 11:59:26 AM UTC-7 Jan Mercl wrote: > On Sun, Oct 2, 2022 at 8:52 PM rob <drro...@gmail.com> wrote: > > > When I do that, I get this error: > > > > panic: sync: negative WaitGroup number > > I tried to investigate, but the code does not build. > > ./main.go:99:11: undefined: globCommandLineFiles > ./main.go:101:11: undefined: commandLineFiles > > Can you please make it a self-contained, minimal program that > reproduces the failure? > -- 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/efec7a69-0e00-4bc5-a2aa-5c03e3009f05n%40googlegroups.com.
