-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
contexts: always call returned cancelFunc #822
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
Comments
Is this the case even if the parent context cancels? The only time ive thrown away cancel funcs is if im confident my parent will cancel for me |
that's a bit error prone-- if others change the code above you it will break things. probably safer to cancel always. |
so @whyrusleeping's assumptions holds but I agree with @jbenet that it is error prone. If the parent changes to a non-canceling one for instance. |
pushed fix for the ones in PR860 that @jbenet linked to. (df4d510) here is a list of outstanding ones
|
awesome. might try grepping just |
agreed and updated :) rebased btw |
@cryptix which PR? |
it's still a branch only - I guess I can open one now. |
closing in favor of #878. |
Hi,
according to this upstream change, we can't ignore the returned cancelFunc of a context otherweise cleanup of goroutines blocking on
ctx.Done()
can't happend.I found at one such case in routing/dht/records.go and started a branch (dontIgnoreCancelFuncs) with a fix but wanted to wait with a PR until we are sure there arn't more easy cases lying around.
The text was updated successfully, but these errors were encountered: