1. 14 Apr, 2014 15 commits
  2. 12 Apr, 2014 1 commit
  3. 11 Apr, 2014 16 commits
  4. 10 Apr, 2014 8 commits
    • Rob Pike's avatar
      doc/go1.3.html: fix spelling mistakes · 1d879fe7
      Rob Pike authored
      Keep those builders busy.
      
      LGTM=bradfitz
      R=golang-codereviews, bradfitz
      CC=golang-codereviews
      https://golang.org/cl/85710046
      1d879fe7
    • Brad Fitzpatrick's avatar
      bytes, strings: add Reader.ReadAt race tests · 2dbc5d26
      Brad Fitzpatrick authored
      Tests for the race detector to catch anybody
      trying to mutate Reader in ReadAt.
      
      LGTM=gri
      R=gri
      CC=golang-codereviews
      https://golang.org/cl/86700043
      2dbc5d26
    • Brad Fitzpatrick's avatar
      doc: finish net/http notes in go1.3.html · 1e68e6ae
      Brad Fitzpatrick authored
      LGTM=r
      R=r
      CC=golang-codereviews
      https://golang.org/cl/86580043
      1e68e6ae
    • Alexey Borzenkov's avatar
      net/http: fix requests failing on short gzip body · 0944837f
      Alexey Borzenkov authored
      Fixes #7750.
      
      LGTM=bradfitz
      R=golang-codereviews, ibilicc, bradfitz
      CC=golang-codereviews
      https://golang.org/cl/84850043
      0944837f
    • Russ Cox's avatar
      runtime: make times in GODEBUG=gctrace=1 output clearer · 5539ef02
      Russ Cox authored
      TBR=0intro
      CC=golang-codereviews
      https://golang.org/cl/86620043
      5539ef02
    • Keith Randall's avatar
      cmd/6g: nacl: zero odd multiple of widthptr correctly · bfbb2e82
      Keith Randall authored
      LGTM=iant
      R=remyoudompheng, iant
      CC=golang-codereviews
      https://golang.org/cl/86270043
      bfbb2e82
    • Rui Ueyama's avatar
      sync: fix spurious wakeup from WaitGroup.Wait · e9347c78
      Rui Ueyama authored
      There is a race condition that causes spurious wakeup from Wait
      in the following case:
      
       G1: decrement wg.counter, observe the counter is now 0
           (should unblock goroutines queued *at this moment*)
       G2: increment wg.counter
       G2: call Wait() to add itself to the wait queue
       G1: acquire wg.m, unblock all waiting goroutines
      
      In the last step G2 is spuriously woken up by G1.
      Fixes #7734.
      
      LGTM=rsc, dvyukov
      R=dvyukov, 0xjnml, rsc
      CC=golang-codereviews
      https://golang.org/cl/85580043
      e9347c78
    • Brad Fitzpatrick's avatar
      net/http: don't reuse Transport connection unless Request.Write finished · 6278a954
      Brad Fitzpatrick authored
      In a typical HTTP request, the client writes the request, and
      then the server replies. Go's HTTP client code (Transport) has
      two goroutines per connection: one writing, and one reading. A
      third goroutine (the one initiating the HTTP request)
      coordinates with those two.
      
      Because most HTTP requests are done when the server replies,
      the Go code has always handled connection reuse purely in the
      readLoop goroutine.
      
      But if a client is writing a large request and the server
      replies before it's consumed the entire request (e.g. it
      replied with a 403 Forbidden and had no use for the body), it
      was possible for Go to re-select that connection for a
      subsequent request before we were done writing the first. That
      wasn't actually a data race; the second HTTP request would
      just get enqueued to write its request on the writeLoop. But
      because the previous writeLoop didn't finish writing (and
      might not ever), that connection is in a weird state. We
      really just don't want to get into a state where we're
      re-using a connection when the server spoke out of turn.
      
      This CL changes the readLoop goroutine to verify that the
      writeLoop finished before returning the connection.
      
      In the process, it also fixes a potential goroutine leak where
      a connection could close but the recycling logic could be
      blocked forever waiting for the client to read to EOF or
      error. Now it also selects on the persistConn's close channel,
      and the closer of that is no longer the readLoop (which was
      dead locking in some cases before). It's now closed at the
      same place the underlying net.Conn is closed. This likely fixes
      or helps Issue 7620.
      
      Also addressed some small cosmetic things in the process.
      
      Update #7620
      Fixes #7569
      
      LGTM=adg
      R=golang-codereviews, adg
      CC=dsymonds, golang-codereviews, rsc
      https://golang.org/cl/86290043
      6278a954