mirror of
https://github.com/golang/net.git
synced 2026-03-31 18:37:08 +09:00
If the test gets completely stuck at these points, we will want a goroutine dump in order to debug the hang, which log.Fatalf will not produce (but a test timeout will). If the test does not get completely stuck (as on a slow or overloaded builder), then we should let it continue to run until the overall test timeout, which (unlike hard-coded constants) should already take the speed of the builder into account. As a side-effect, this also moves some t.Fatalf calls out of background goroutines and into the main test-function goroutines where they belong (see golang/go#24678). Fixes golang/go#52051. Change-Id: I37504081e6fdf0b4c244305fc83c575e30b7b453 Reviewed-on: https://go-review.googlesource.com/c/net/+/410096 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>