Commit 516f0d1c authored by Daniel Morsing's avatar Daniel Morsing

net/http: silence race detector on client header timeout test

When running the client header timeout test, there is a race between
us timing out and waiting on the remaining requests to be serviced. If
the client times out before the server blocks on the channel in the
handler, we will be simultaneously adding to a waitgroup with the
value 0 and waiting on it when we call TestServer.Close().

This is largely a theoretical race. We have to time out before we
enter the handler and the only reason we would time out if we're
blocked on the channel. Nevertheless, make the race detector happy
by turning the close into a channel send. This turns the defer call
into a synchronization point and we can be sure that we've entered
the handler before we close the server.

Fixes #10780

Change-Id: Id73b017d1eb7503e446aa51538712ef49f2f5c9e
Reviewed-on: https://go-review.googlesource.com/9905Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
parent 4212a3c3
......@@ -927,7 +927,14 @@ func TestClientTimeout_Headers(t *testing.T) {
<-donec
}))
defer ts.Close()
defer close(donec)
// Note that we use a channel send here and not a close.
// The race detector doesn't know that we're waiting for a timeout
// and thinks that the waitgroup inside httptest.Server is added to concurrently
// with us closing it. If we timed out immediately, we could close the testserver
// before we entered the handler. We're not timing out immediately and there's
// no way we would be done before we entered the handler, but the race detector
// doesn't know this, so synchronize explicitly.
defer func() { donec <- true }()
c := &Client{Timeout: 500 * time.Millisecond}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment