Skip to content

G
golang
Switch branch/tag
  1. 14 Apr, 2014 13 commits
  3. 12 Apr, 2014 1 commit
  5. 11 Apr, 2014 16 commits
  7. 10 Apr, 2014 10 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
    • David du Colombier's avatar
      runtime: no longer skip stack growth test in short mode · d7ac73c8
      David du Colombier authored 
      We originally decided to skip this test in short mode
to prevent the parallel runtime test to timeout on the
Plan 9 builder. This should no longer be required since
the issue was fixed in CL 86210043.

LGTM=dave, bradfitz
R=dvyukov, dave, bradfitz
CC=golang-codereviews, rsc
https://golang.org/cl/84790044
      d7ac73c8
    • David du Colombier's avatar
      runtime: fix semasleep on Plan 9 · 5a513061
      David du Colombier authored 
      If you pass ns = 100,000 to this function, timediv will
return ms = 0. tsemacquire in /sys/src/9/port/sysproc.c
will return immediately when ms == 0 and the semaphore
cannot be acquired immediately - it doesn't sleep - so
notetsleep will spin, chewing cpu and repeatedly reading
the time, until the 100us have passed.

Thanks to the time reads it won't take too many iterations,
but whatever we are waiting for does not get a chance to
run. Eventually the notetsleep spin loop returns and we
end up in the stoptheworld spin loop - actually a sleep
loop but we're not doing a good job of sleeping.

After 100ms or so of this, the kernel says enough and
schedules a different thread. That thread manages to do
whatever we're waiting for, and the spinning in the other
thread stops. If tsemacquire had actually slept, this
would have happened much quicker.

Many thanks to Russ Cox for help debugging.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/86210043
      5a513061