Minor cleanup with concurrency and locking

[abhi]

Signed-off-by: Abhinandan Prativadi abhi@docker.com

[codecov-io]

Codecov Report

Merging #26 into master will increase coverage by 1.09%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master      #26      +/-   ##
==========================================
+ Coverage   40.46%   41.55%   +1.09%     
==========================================
  Files           8        8              
  Lines         304      296       -8     
==========================================
  Hits          123      123              
+ Misses        152      144       -8     
  Partials       29       29

Impacted Files	Coverage Δ
opts.go	16.19% <ø> (-0.34%)	⬇️
cni.go	64.06% <71.42%> (+1.15%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47457ea...1695039. Read the comment docs.

[Random-Liu]

I understand embedded RLock has no problem, but I still prefer having a separate status helper function which doesn't grab a lock, and change all public functions to use it.

Other than this LGTM.

[abhi]

@Random-Liu yes. The only reason is between status check and the actual setup we might have an update so It might be better to avoid the race by the embedded RLock is what I think.

[Random-Liu]

@abhi I mean you can have an internal status function which doesn't have lock, and change Status, Setup, and Remove to use the internal status. In this way, you don't need embedded RLock and get the same result.

[abhi]

@Random-Liu done

[Random-Liu]

LGTM