-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix a goroutine misusage in the implementation of Worker.Subscribe() #1775
Conversation
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Current coverage is 55.05% (diff: 0.00%)@@ master #1775 diff @@
==========================================
Files 102 102
Lines 16871 16871
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
- Hits 9294 9288 -6
- Misses 6419 6428 +9
+ Partials 1158 1155 -3
|
ping @aluzzardi ptal |
LGTM |
2 similar comments
LGTM |
LGTM |
Classic! |
BTW, is there any static code checking tool for this "common mistake"? |
I don't know of any, but I think it would be a very good addition to |
@AkihiroSuda @aaronlehmann Just don't do it. ;) The best way to understand why this is to think of the for loop variables like this: { // enclosing block
var tm *taskManager
for tm = range taskManagers {
// tm gets a new value on each iteration.
}
} Checkout https://play.golang.org/p/Bat8jtGgEh. It results in all goroutines printing last value of i. tm as a pointer works the same way. The way around this is to create new variable, on each loop, and let that get closed: { // enclosing block
var tm *taskManager
for tm = range taskManagers {
tm := tm
// tm gets a new value on each iteration.
}
} The above creates a new Really, this could be caught with the race detector. |
Fix moby/moby#28915
Signed-off-by: Akihiro Suda suda.akihiro@lab.ntt.co.jp