proposal: Replace Context with goroutine-local storage

[neild]

This is a bit pie-in-the sky, but I think worth considering even if only to reject it.

One of the original motivations for the Context type was to provide a way to plumb distributed trace IDs (as used by e.g., Dapper: https://research.google.com/pubs/pub36356.html) though the call stack.

The Context type suffices to connect inbound and outbound RPCs by passing a trace ID from the inbound request handler to the outbound call, but it leaves significant gaps. In particular, distibuted profiling tools may need to associate trace IDs with specific goroutines in order to, for example, associate CPU time or memory allocations with specific inbound requests. This requires some form of goroutine tagging; e.g., http://golang.org/cl/43751.

Another aspect of Contexts is that for them to be useful, they must be pervasive. The entire purpose of a Context is to plumb values through layers of the call stack that don't care about them--e.g., to pass a cancellation signal or trace id through unrelated layers of code down to the place where a file is written or an RPC call made. This requires that almost every package become Context-aware. This is not, I think, a significant cost, but it is a cost. It is not difficult to find users complaining about the need to add Context parameters to their functions.

Given that goroutine tagging (a form of goroutine-local storage) may be necessary to support some profilers, should we consider replacing Context entirely with goroutine-local storage? Cancellation becomes a goroutine-local 'done' channel. Trace IDs are a goroutine-local value. Profile tags (if distinct from trace IDs) are just another value. The io.Reader/io.Writer interfaces can trivially support cancelation without modification. Existing packages can be retrofitted to support cancellation/value propagation without API changes.

A significant downside is that this would replace a fairly simple interface built from existing components with a language feature. I'm not convinced that this is an improvement. I think it's worth consideration, however.

[ianlancetaylor]

We (well, @matloob) have put a fair amount of effort into making profiling tags work well with contexts.

In particular, the current approach provides mechanisms for running a goroutine with a new set of labels (this mechanism is unfortunately not very well documented at present). This proposal needs to explain how the go statement handles goroutine-local storage.

[neild]

A bit more concretely:

• Each goroutine has, effectively, a local map[interface{}]interface{}.
• New goroutines inherit the contents of the parent goroutine's local storage.
• There is a mechanism for setting the local storage within a lexical scope. (e.g., local.Set(k, v, func() { /* k = v in this scope */ }.)

To run a goroutine with a specific set of labels rather than inheriting the current set, you would temporarily change the current goroutine's labels.

[ianlancetaylor]

For clarity: does a new goroutine inherit the map value, or does it inherit a copy of the map?

[neild]

A new goroutine would inherit a copy of the parent's map, not the actual map. (That wouldn't be very local.)

In simple cases, such as a function which starts some worker goroutines and waits for them to complete before returning, this should propagate cancellation or trace ids correctly with no effort on the user's part. More complex cases, such as long-running worker goroutines which service requests with their own cancellation, are of course still tricky.

[uluyol]

How would this work with worker pools? Consider systems which needs to do work in C or syscalls (e.g. write data to disk, RocksDB, sqlite). Right now you can bound your thread count by using a persistent worker pool. With context.Context, you can just send the context over the channel to keep tracing/logging info.

With GLS, it seems that you'd either need to have some way of copying this over to an existing goroutine, or you'd have to spawn a new goroutine per request and maintain some sort of counter to limit the number overall.

[neild]

Worker pools do need to have some way of associating work with a trace id/etc. With GLS, you would still need some Context-like object which can be passed to workers.

// Start a worker goroutine.
go func() {
  for req := range requestc {
    // Set the trace id, cancellation, etc. for this goroutine while processing this request.
    local.SetMap(req.ctx, func() {
      // Request processing goes here.
    })
  }
}()

This is more code for worker pools (although hopefully not much) in return for less in code which does not share a goroutine across multiple, independent operations.

Note that tracing systems which associate CPU time or allocations to specific requests still require that pool goroutines be temporarily associated with a particular trace tag. (c.f., http://golang.org/cl/43751) Arguably, using GLS makes it clearer to the authors of packages that use worker pools that this association may be necessary.

[earthboundkid]

Merovius has a blog post arguing for GLS: https://blog.merovius.de/2017/08/14/why-context-value-matters-and-how-to-improve-it.html

It seems persuasive to me, but I also know that a lot of people have negative feelings about TLS and would not like Go to adopt a TLS-like mechanism.

I think if we follow Merovius's approach, we should make package-level variables GLS by default and use a keyword to make them non-sync shared mutable, which ISTM would be a rare thing to want.

[ianlancetaylor]

I don't understand the middleware argument in Merovius's blog post: why can't I use a function closure to pass my values through middleware?

Personally I think that dynamic scoping is a recipe for confusion. It's better to represent it explicitly rather than implicitly. Same for goroutine-local storage. Being explicit makes things very clear.

[Merovius]

@ianlancetaylor I'm not sure what you mean with your question about the function closure. If I would, I'd be happy to try to explain what I'd see as a problem :) Say, for example, I want request-specific debug logging, e.g. using a X-Log-Verbosity: Debug header or the like. With context, an easy way to do that is (kind of handwaving an API here, try and focus on the essential ideas)

func SetVerbosity(h http.Handler) http.Handler {
    return http.HandlerFunc(res http.ResponseWriter, req *http.Request) {
        ctx := req.Context()
        ctx = context.WithValue(ctx, ctxVerbosity, parseVerbosity(req.Header.Get("X-Log-Verbosity")))
        req = req.WithContext(ctx)
        h(res, req)
    })
}

func Logf(ctx context.Context, v int, format string, vals ...interface{}) {
    if rv, _ := context.Value(ctxVerbosity).(int); rv >= v {
       log.Printf(format, vals...)
    }     
}

func main() {
    h := http.Handler(http.HandlerFunc(serve))
    h = SetVerbosity(h)
    http.ListenAndServe(":0", h)
}

func serve(res http.ResponseWriter, req *http.Request) {
    Logf(req.Context(), Debug, "Doing things!")
}

Now, how would this look without context? (You could argue, that the header-parsing doesn't have to happen in a middleware and could instead happen directly from a passed *http.Request in the handler, to which I'd respond that *http.Request.Header is just a string-based, http-specific version of context)

I don't understand how closures would help - to me, that would at best replace the question "how do I pass an int through an API" with "how do I pass a func() int through an API". I'm very much ready to be convinced otherwise, though.

---

And FTR, I am also not convinced there actually is much of a problem with context.Context - I tend to agree with Sameer here that most criticism of context seems to be opinion not really experience (that includes my article). I also tend to agree after some convincing, that the explicit nature of context is advantageous. I just wanted to separate out the different criticisms of context, taken at face value. And as much as possible distill its usefulness (though I probably did a bad job with that). Because I think depending on what you decide is bad about it, there might be alternative solutions.

[bcmills]

@uluyol

How would this work with worker pools? […] Right now you can bound your thread count by using a persistent worker pool.

With GLS, […] you'd have to spawn a new goroutine per request and maintain some sort of counter to limit the number overall.

In my experience, a semaphore tends produce a much cleaner API than a goroutine pool anyway: it does not require an explicit Close or Stop call to shut down background goroutines, and does not pollute goroutine dumps with idle workers in the event of a crash.

If the structure of context-passing discourages the "goroutine pool" pattern, I'd call that a feature, not a bug.

[ianlancetaylor]

@Merovius You're right, of course: if you want to pull a value from the HTTP request, and let that value influence the behavior of other functions invoked by the request, then you must pass that value to those functions in some way. You can pass the value in a Context, or you can pass down a function value (in your example a log function that invokes Logf with the right verbosity), but either way something must be passed explicitly.

I agree that goroutine-local variables avoid the need for explicit argument passing, but I also think they add considerable conceptual complexity.

[bcmills]

[F]or [Contexts] to be useful, they must be pervasive.

A somewhat less invasive way to reduce the syntactic overhead of Context would be to make it a built-in type (like error).

That would at least cut the stutter by a third:

-func Foo(ctx context.Context) error {
+func Foo(ctx context) error {