Skip to content

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

Closed
cryptix opened this issue Feb 25, 2015 · 10 comments
Closed

contexts: always call returned cancelFunc #822

cryptix opened this issue Feb 25, 2015 · 10 comments
Labels
kind/bug A bug in existing code (including security flaws)

Comments

@cryptix
Copy link
Contributor

cryptix commented Feb 25, 2015

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.

@cryptix cryptix added the kind/bug A bug in existing code (including security flaws) label Feb 25, 2015
@whyrusleeping
Copy link
Member

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

@jbenet
Copy link
Member

jbenet commented Feb 27, 2015

that's a bit error prone-- if others change the code above you it will break things. probably safer to cancel always.

@whyrusleeping whyrusleeping changed the title contexst: always call returned cancelFunc contexts: always call returned cancelFunc Feb 27, 2015
@jbenet
Copy link
Member

jbenet commented Mar 6, 2015

@cryptix
Copy link
Contributor Author

cryptix commented Mar 7, 2015

The returned context's Done channel is closed when the returned cancel function is called or when the parent context's Done channel is closed, whichever happens first. - godoc

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.

@cryptix
Copy link
Contributor Author

cryptix commented Mar 7, 2015

pushed fix for the ones in PR860 that @jbenet linked to. (df4d510)

here is a list of outstanding ones

[cryptix@higgs ~/go/src/github.com/jbenet/go-ipfs] grep -R '_ := context.' | grep -v Godeps | grep -v _test.go  | sort
core/commands/id.go:            ctx, _ := context.WithTimeout(context.TODO(), time.Second*5)
core/commands/ping.go:                  ctx, _ := context.WithTimeout(ctx, kPingTimeout)
core/commands/ping.go:                  ctx, _ := context.WithTimeout(ctx, kPingTimeout)
core/corenet/net.go:    ctx, _ := context.WithTimeout(nd.Context(), time.Second*30)
diagnostics/diag.go:    ctx, _ := context.WithTimeout(context.TODO(), timeout)
exchange/bitswap/bitswap.go:                    child, _ := context.WithTimeout(ctx, providerRequestTimeout)
exchange/bitswap/bitswap.go:            hasBlockCtx, _ := context.WithTimeout(ctx, hasBlockTimeout)
merkledag/merkledag.go: ctx, _ := context.WithTimeout(context.TODO(), time.Minute)
namesys/publisher.go:   timectx, _ := context.WithDeadline(ctx, time.Now().Add(time.Second*10))
p2p/net/swarm/swarm_dial.go:            ctxT, _ := context.WithTimeout(ctx, s.dialT)
pin/pin.go:     ctx, _ := context.WithTimeout(context.Background(), time.Second*60)
routing/dht/dht.go:                             ctx, _ := context.WithTimeout(dht.Context(), time.Second*5)
unixfs/tar/reader.go:           ctx, _ := context.WithTimeout(context.TODO(), time.Second*60)

@jbenet
Copy link
Member

jbenet commented Mar 7, 2015

awesome. might try grepping just _ := context.

@cryptix
Copy link
Contributor Author

cryptix commented Mar 7, 2015

agreed and updated :)

rebased btw

@jbenet
Copy link
Member

jbenet commented Mar 7, 2015

@cryptix which PR?

@cryptix
Copy link
Contributor Author

cryptix commented Mar 7, 2015

it's still a branch only - I guess I can open one now.

@cryptix
Copy link
Contributor Author

cryptix commented Mar 7, 2015

closing in favor of #878.

@cryptix cryptix closed this as completed Mar 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

No branches or pull requests

3 participants