code review 51700043: net/http: fix another data race when sharing Request.Body

net/http: fix another data race when sharing Request.Body

Fix another issue (similar to Issue 6995) where there was a
data race when sharing a server handler's Request.Body with
another goroutine that out-lived the Handler's goroutine.

In some cases we were not closing the incoming Request.Body
(which would've required reading it until the end) if we
thought it we thought we were going to be forcibly closing the
underlying net.Conn later anyway. But that optimization
largely moved to the transfer.go *body later, and locking was
added to *body which then detected read-after-close, so now
calling the (*body).Close always is both cheap and correct.

No new test because TestTransportAndServerSharedBodyRace caught it,
albeit only sometimes. Running:

while ./http.test -test.cpu=8 -test.run=TestTransportAndServerSharedBodyRace; do true; done

... would reliably cause a race before, but not now.

Update Issue 6995
Fixes Issue 7092

[bradfitz, 2014-01-13 23:12:56]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[khr, 2014-01-14 04:30:26]

On 2014/01/13 23:12:56, bradfitz wrote:
> Hello mailto:golang-codereviews@googlegroups.com,
> 
> I'd like you to review this change to
> https://go.googlecode.com/hg/

LGTM.

[bradfitz, 2014-01-14 17:46:43]

*** Submitted as https://code.google.com/p/go/source/detail?r=51a204237ba5 ***

net/http: fix another data race when sharing Request.Body

Fix another issue (similar to Issue 6995) where there was a
data race when sharing a server handler's Request.Body with
another goroutine that out-lived the Handler's goroutine.

In some cases we were not closing the incoming Request.Body
(which would've required reading it until the end) if we
thought it we thought we were going to be forcibly closing the
underlying net.Conn later anyway. But that optimization
largely moved to the transfer.go *body later, and locking was
added to *body which then detected read-after-close, so now
calling the (*body).Close always is both cheap and correct.

No new test because TestTransportAndServerSharedBodyRace caught it,
albeit only sometimes. Running:

while ./http.test -test.cpu=8 -test.run=TestTransportAndServerSharedBodyRace; do
true; done

... would reliably cause a race before, but not now.

Update Issue 6995
Fixes Issue 7092

R=golang-codereviews, khr
CC=golang-codereviews
https://codereview.appspot.com/51700043