mirror of
https://github.com/alrayyes/wiki.git
synced 2024-11-29 06:26:22 +00:00
70 lines
2.5 KiB
Markdown
70 lines
2.5 KiB
Markdown
|
---
|
||
|
|
id: ad20518c-1a42-4d02-8746-f42be6a46944
|
||
|
|
title: Golang Context
|
||
|
|
---
|
||
|
|
|
||
|
|
# Overview
|
||
|
|
|
||
|
|
Package context defines the Context type, which carries deadlines,
|
||
|
|
cancellation signals, and other request-scoped values across API
|
||
|
|
boundaries and between processes.
|
||
|
|
|
||
|
|
Incoming requests to a server should create a Context, and outgoing
|
||
|
|
calls to servers should accept a Context. The chain of function calls
|
||
|
|
between them must propagate the Context, optionally replacing it with a
|
||
|
|
derived Context created using WithCancel, WithDeadline, WithTimeout, or
|
||
|
|
WithValue. When a Context is canceled, all Contexts derived from it are
|
||
|
|
also canceled.
|
||
|
|
|
||
|
|
The WithCancel, WithDeadline, and WithTimeout functions take a Context
|
||
|
|
(the parent) and return a derived Context (the child) and a CancelFunc.
|
||
|
|
Calling the CancelFunc cancels the child and its children, removes the
|
||
|
|
parent's reference to the child, and stops any associated timers.
|
||
|
|
Failing to call the CancelFunc leaks the child and its children until
|
||
|
|
the parent is canceled or the timer fires. The go vet tool checks that
|
||
|
|
CancelFuncs are used on all control-flow paths.
|
||
|
|
|
||
|
|
Programs that use Contexts should follow these rules to keep interfaces
|
||
|
|
consistent across packages and enable static analysis tools to check
|
||
|
|
context propagation:
|
||
|
|
|
||
|
|
Do not store Contexts inside a struct type; instead, pass a Context
|
||
|
|
explicitly to each function that needs it. The Context should be the
|
||
|
|
first parameter, typically named ctx:
|
||
|
|
|
||
|
|
``` go
|
||
|
|
func DoSomething(ctx context.Context, arg Arg) error {
|
||
|
|
// ... use ctx ...
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
Do not pass a nil Context, even if a function permits it. Pass
|
||
|
|
context.TODO if you are unsure about which Context to use.
|
||
|
|
|
||
|
|
Use context Values only for request-scoped data that transits processes
|
||
|
|
and APIs, not for passing optional parameters to functions.
|
||
|
|
|
||
|
|
The same Context may be passed to functions running in different
|
||
|
|
goroutines; Contexts are safe for simultaneous use by multiple
|
||
|
|
goroutines.
|
||
|
|
|
||
|
|
See <https://blog.golang.org/context> for example code for a server that
|
||
|
|
uses Contexts.
|
||
|
|
|
||
|
|
# Googles take
|
||
|
|
|
||
|
|
> At Google, we require that Go programmers pass a Context parameter as
|
||
|
|
> the first argument to every function on the call path between incoming
|
||
|
|
> and outgoing requests. This allows Go code developed by many different
|
||
|
|
> teams to interoperate well. It provides simple control over timeouts
|
||
|
|
> and cancelation and ensures that critical values like security
|
||
|
|
> credentials transit Go programs properly.
|
||
|
|
|
||
|
|
# A saner take on this which I as a Go noob agree with
|
||
|
|
|
||
|
|
- Context should go away for Go 2[^1]
|
||
|
|
|
||
|
|
# Footnotes
|
||
|
|
|
||
|
|
[^1]: <https://faiface.github.io/post/context-should-go-away-go2/>
|