Not handling error in walkfunc leads to double close on kill channel

[matchstick]

I am finding a possible race condition which causes a panic.

It occurs on 4 or 8 cpu systems. On a single CPU system it does not occur.

When invoking walk on a directory with 14 files to be processed and one returns an error, you get a double close on the "kill" channel on line 113.

Here are the repeatable sequence of events.

1. All 14 of the files are queued up at line 95 very quickly. So they are all enqueued at the channel. None of them have processed yet or been dequeued from the channel.

2. Execution then takes us to line 112. We have hit no error yet. And the call to walkerWg.Wait() on line 109 is not blocking. This is probably not intended as none of the go routines have been enqueued from the channel. But it makes sense looking at the code to see the main thread of execution not blocked. On line 113 it closed the "kill" channel with "close(kill)"

3. Then the workers get dequeued.

4. One of them has an error. It closes the kill channel on line 76.

While the symptom is not good. The reality is that the WalkLimit routine ends with outstanding go routines still running when an error is encountered. This can mask the real problem outside of the powerwalk code. That is probably not expected behaviour.

If you want I can try to recreate this behaviour in your test set up.

Here is stack backtrace.

panic: close of closed channel

goroutine 1 [running]:
github.com/stretchr/powerwalk.WalkLimit(0x7fff705d73c9, 0x12, 0x976538, 0x64, 0xc0001cdc80, 0x4d9a8f)
/home/.../go/pkg/mod/github.com/stretchr/[email protected]/walker.go:113 +0x24e
github.com/stretchr/powerwalk.Walk(...)
/home/.../go/pkg/mod/github.com/stretchr/[email protected]/walker.go:24