proposal: context: allow creation of new context with only values inherited

[johanbrandhorst]

What version of Go are you using (go version)?

go 1.11

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="~/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="~/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build965718044=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Tried creating a new context which inherits everything but the deadline of the parent.

What did you expect to see?

I expected there to be a method with which I can create a child without the deadline associated with the parent.

What did you see instead?

There was no easy way to accomplish this.

The need arises when you want to, for example, create a new goroutine with a different lifetime from the current goroutine, but you still want it to have all the same values associated with the original goroutines context.

I searched for any similar issues but couldn't find any, apologies if this has already been discussed.

[meirf]

There's been some discussion about how context.Context should be used. It seems like this proposal could cause misuse by having users think of context with in ways totally unrelated to lifecycle management.

This experience report has some insights on this:

While opinions differs on many aspects of context.Context, one thing is clear–there is almost unanimous agreement that the Context.WithValue method on the context.Context interface is orthogonal to the type’s role as a mechanism to control the lifetime of request scoped resources.

@davecheney what do you think?

[johanbrandhorst]

My specific use case is for propagating OpenCensus tags, trace and span IDs into a goroutine with a different lifetime from the parent. These are all stored as values in the context, and have separate getters and setters, so you end up with things like

ctx = trace.NewContext(tag.NewContext(context.Background, tag.FromContext(ctx)), trace.FromContext(ctx))

This still doesn't include other values you may want to propagate either, so it only feels like a bandaid.

[rsc]

Context is an interface, so you can always write a new Context implementation that falls back to the old context for value lookups. Is that enough? If so, this is a duplicate of #26691. It's still not clear this must be added to the standard library when it's so easy to implement outside.

/cc @neild @bcmills @Sajmani

[johanbrandhorst]

Interesting point, that definitely makes sense and it could be implemented wherever it's needed. I'm happy enough with that so this can be considered a duplicate.

[andybons]

Closing per last comment. Thanks.