The context tests were flaky under Go 1.6 on Windows. Make them
slower, but make up for the slowness by parallelizing them.
These tests don't run on Go 1.7+ in the subrepo. They were deflaked in
the standard library's context in Go 1.7.
Updates golang/go#11811
Change-Id: I8dc8d9e13e72e87b4444e92d2316dd95bd7d066d
Reviewed-on: https://go-review.googlesource.com/34288
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CancelFunc was the only part of the context package which didn't
forward nicely with the move from x/net/context to std context.
Use it for Context as well.
Change-Id: Ieff39b10b0783d55d0437c73923053297ed0ea4a
Reviewed-on: https://go-review.googlesource.com/32317
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The Go 1.4 (and earlier) support for request cancellation is racy and
complicates the implementation of ctxhttp. This change simply inlines
the existing 1.5+ cancellation logic directly, and removes support for
older versions.
Change-Id: I7df9f0648dd0e571366374d079e2976050464ca3
Reviewed-on: https://go-review.googlesource.com/22302
Reviewed-by: David Symonds <dsymonds@golang.org>
Run-TryBot: David Symonds <dsymonds@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cancelCtx has an embedded sync.Mutex. This change causes an extra
allocation when creating a new timerCtx via WithDeadline, but that seems
minor when compared with better locking discipline. If it turns out to
be a problem, the whole cancelCtx struct can be flattened into timerCtx.
Addresses part of golang/go#14839.
Change-Id: Ie86ed1b63592b521aefde747d5fafcd49ac18178
Reviewed-on: https://go-review.googlesource.com/20840
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
plan9's network deadline & cancelation code is so brittle that it's
not even worth testing this package there. It only results in 10
minute deadlocks and slows down the trybots which should be ~30
seconds, not 10 minutes.
Change-Id: I097a885ae5887f0ecf357611aa7fae8885e18e05
Reviewed-on: https://go-review.googlesource.com/18578
Reviewed-by: Chris Broadfoot <cbro@golang.org>
This is necessary for cleanup of any goroutine that blocks on
ctx.Done(), as is done in e.g. propagateCancel in context.go. It is
already specified for WithTimeout and WithDeadline, whose descriptions I
have simplified here.
Change-Id: I6b30605decb8c0b7c1296c3f8852f9ad305ad4b7
Reviewed-on: https://go-review.googlesource.com/5022
Reviewed-by: Sameer Ajmani <sameer@golang.org>
The current example leaks the DoSomethingSlow goroutine for an
arbitrarily long time. In a real server, that can lead to an
out-of-memory failure during events such as network outages; a
more careful version of that example would be too long for a
simple package doc.
Fortunately, there are other short, common patterns using Done
that don't leak and don't require a lot of explanation. Let's
use one of those instead.
Change-Id: I0ad0c6121d06b757a397e0e71be9e01ccfd75f77
Reviewed-on: https://go-review.googlesource.com/4490
Reviewed-by: Andrew Gerrand <adg@golang.org>
The point of the DoSomething function is to protect the user from
DoSomethingSlow, which presumably doesn't support returning early upon
cancellation and deadline expiration (or else DoSomething wouldn't need
to exist).
Since most of the point of the Context object is communicating deadline
and cancellation, it is misleading for DoSomethingSlow to accept a
context object. A function like DoSomething is only likely to be written
when wrapping other code that doesn't properly support contexts.
Change-Id: Ibdef5b7ed71387ba6a09179ef2f911fc3f98e40a
Reviewed-on: https://go-review.googlesource.com/3902
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Recent runtime changes mean that these are stored indirectly, requiring additional allocation.
LGTM=adonovan
R=rsc, bradfitz, adonovan
CC=golang-codereviews
https://golang.org/cl/148590043
It seems like it was meant to be this way. There was already a for loop, but then it made a recursive call instead.
LGTM=sameer
R=golang-codereviews, sameer
CC=golang-codereviews
https://golang.org/cl/113540044
to construct the context left-to-right. External implementations of the
Context interface may break the chain, but establishing this pattern now
may encourage them to do the right thing.
LGTM=bcmills
R=bcmills
CC=golang-codereviews
https://golang.org/cl/116430044
WithCancel, and WithTimeout to use different concrete types. Update the
tests and documentation.
This change reduces the size of context structs, reduces the number of
allocations (see TestAllocs) and removes unnecessary pointers from the
heap, such as the timer field for non-timer contexts.
IMPORTANT: I've removed the code in these functions that handles nil Context parameters. Passing a nil parent Context will now cause a panic.
LGTM=bcmills
R=bcmills, crawshaw
CC=adonovan, golang-codereviews, rsc
https://golang.org/cl/116400043
This is the first step in splitting the various context implementations
into smaller types.
Add a test that creates a large, random stack of Contexts and tests that
they work properly.
LGTM=crawshaw
R=crawshaw
CC=golang-codereviews
https://golang.org/cl/115350044
makes the Context interface dependent only on standard packages, which
means types in other packages can implement this interface without
depending on go.net/context.
Remove the NewKey function and add examples showing how to use
unexported types to avoid key collisions. This is the same model used
by http://www.gorillatoolkit.org/pkg/context, except we associate values
with a specific Context instead of storing them in a package-level map.
LGTM=crawshaw
R=golang-codereviews, crawshaw, dsymonds
CC=golang-codereviews, rsc
https://golang.org/cl/104480044
Do not assume that a particular code path is selected
in WithTimeout.
Also Windows cannot wait for less then 15 millisecond,
so use that instead of 1 nanosecond in test. Otherwise
test takes too long while it looks like it is quick.
Fixesgolang/go#8033.
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/103470044
deadlines, cancellation, and other values across APIs and between
processes.
LGTM=crawshaw
R=rsc, crawshaw
CC=bradfitz, golang-codereviews
https://golang.org/cl/99330045
