4d7a4171cd
If a GC claim is written and then volume is deleted before the `volumewatcher` enters its run loop, we panic on the nil-pointer access. Simply doing a nil-check at the top of the loop reveals a race condition around shutting down the loop just as a new update is coming in. Have the parent `volumeswatcher` send an initial update on the channel before returning, so that we're still holding the lock. Update the watcher's `Stop` method to set the running state, which lets us avoid having a second context and makes stopping synchronous. This reduces the cases we have to handle in the run loop. Updated the tests now that we'll safely return from the goroutine and stop the runner in a larger set of cases. Ran the tests with the `-race` detection flag and fixed up any problems found here as well. |
||
|---|---|---|
| .. | ||
| interfaces.go | ||
| interfaces_test.go | ||
| volume_watcher.go | ||
| volume_watcher_test.go | ||
| volumes_watcher.go | ||
| volumes_watcher_test.go | ||