In -test.short mode, skip measuring the upper bound of time
sleeps. The API only guarantees minimum bounds on sleeps,
anyway, so this isn't a bug we're ignoring as much as it is
simply observing bad builder virtualization and/or loaded
machines.
We keep the test in full mode where developers will
presumably be running on a lightly-loaded, native, fast
machine.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5713044
before after
go test -short time 4.144s 1.215s
go test -short runtime 1.315s 0.351s
go test -short -cpu=1,2,4 runtime 4.376s 1.266s
Partially solves issue 3015.
R=golang-dev, r
CC=golang-dev, remy
https://golang.org/cl/5673045
I'm in two minds as to whether this should be a function of gotest.
Tests that can flake out like this should be rare enough that we
needn't add more mechanism.
R=r
CC=golang-dev
https://golang.org/cl/4335042
Also simplify sleeper algorithm and poll
occasionally so redundant sleeper goroutines
will quit sooner.
R=r, niemeyer, r2
CC=golang-dev
https://golang.org/cl/4063043
The After code is trivially generalisable to provide support
for this, and it is possible to use AfterFunc to do
things that After cannot, such as waiting
for many events at varied times without an overhead
of one goroutine per event.
R=rsc, r
CC=golang-dev
https://golang.org/cl/3905041
Permits one to easily put a timeout in a select:
select {
case <-ch:
// foo
case <-time.After(1e6):
// bar
}
R=r, rog, rsc, sameer1, PeterGo, iant, nigeltao_gnome
CC=golang-dev
https://golang.org/cl/2321043
