qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-10-01 01:18:32 -06:00
Code Releases Activity

net/http/httptest: fix deadlock in TestIssue7264

Browse Source 
I am seeing deadlocks waiting on <-inHandler.
It seems to me that there is no guarantee that the
handler actually runs, if the client does

        write header
        close connection

fast enough. The server might see the EOF on the
connection before it manages to invoke the handler.

This change fixes the deadlock, but it may make
the test not actually test anything. Not sure.

LGTM=bradfitz
R=bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/140970043
This commit is contained in:
Russ Cox 2014-09-07 20:13:35 -04:00
parent b4bfa6c964
commit 902f8d9ca0
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/pkg/net/http/httptest/server_test.go
View File

@ -32,10 +32,7 @@ func TestServer(t *testing.T) {
func TestIssue7264(t *testing.T) {
for i := 0; i < 1000; i++ {
func() {
inHandler := make(chan bool, 1)
ts := NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
inHandler <- true
}))
ts := NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {}))
defer ts.Close()
tr := &http.Transport{
ResponseHeaderTimeout: time.Nanosecond,
@ -43,7 +40,10 @@ func TestIssue7264(t *testing.T) {
defer tr.CloseIdleConnections()
c := &http.Client{Transport: tr}
res, err := c.Get(ts.URL)
<-inHandler
// err can be non-nil here.
// If the client writes the header and then immediately observes
// the timeout and closes the connection, the server might never
// have gotten a chance to send a response. That's okay.
if err == nil {
res.Body.Close()
}