Skip to content

G
go
Switch branch/tag
  1. 06 Jan, 2016 27 commits
  3. 05 Jan, 2016 13 commits
    • Brad Fitzpatrick's avatar
      A+C: automated update · ace1738f
      Brad Fitzpatrick authored 
      These are the easy, automated cases. There were some more where we
need to fight Gerrit and the CLA system to extract the appropriate
metadata.

Updates #12042

Change-Id: Id63ae635ee7efeec4cd372c7d85bb5b1f557951b
Reviewed-on: https://go-review.googlesource.com/18264Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      ace1738f
    • Brad Fitzpatrick's avatar
      log/syslog: document that syslog is frozen · ddc25081
      Brad Fitzpatrick authored 
      Try to reduce feature request bug reports.

Change-Id: I713bb715d25d23e084b054aea8e1c3197dde90d4
Reviewed-on: https://go-review.googlesource.com/18222Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      ddc25081
    • Brad Fitzpatrick's avatar
      net/http: make Client use Request.Cancel for timeouts instead of CancelRequest · 7de71c85
      Brad Fitzpatrick authored 
      In the beginning, there was no way to cancel an HTTP request.

We later added Transport.CancelRequest to cancel an in-flight HTTP
request by breaking its underlying TCP connection, but it was hard to
use correctly and didn't work in all cases. And its error messages
were terrible. Some of those issues were fixed over time, but the most
unfixable problem was that it didn't compose well. All RoundTripper
implementations had to choose to whether to implement CancelRequest
and both decisions had negative consequences.

In Go 1.5 we added Request.Cancel, which composed well, worked in all
phases, had nice error messages, etc. But we forgot to use it in the
implementation of Client.Timeout (a timeout which spans multiple
requests and reading request bodies).

In Go 1.6 (upcoming), we added HTTP/2 support, but now Client.Timeout
didn't work because the http2.Transport didn't have a CancelRequest
method.

Rather than add a CancelRequest method to http2, officially deprecate
it and update the only caller (Client, for Client.Cancel) to use
Request.Cancel instead.

The http2 Client timeout tests are enabled now.

For compatibility, we still use CancelRequest in Client if we don't
recognize the RoundTripper type. But documentation has been updated to
tell people that CancelRequest is deprecated.

Fixes #13540

Change-Id: I15546b90825bb8b54905e17563eca55ea2642075
Reviewed-on: https://go-review.googlesource.com/18260Reviewed-by: default avatarAndrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      7de71c85
    • Robert Griesemer's avatar
      spec: New year, new spec update (to refer to Unicode 8.0). · 212bdd95
      Robert Griesemer authored 
      Slightly rephrased sentence to emphasize the contents of the
Unicode categories w/o repeating the full category name each
time.

Fixes #13414.

Change-Id: Icd32ff1547fa81e866c5937a631c3344bb6087c6
Reviewed-on: https://go-review.googlesource.com/18265Reviewed-by: default avatarRob Pike <r@golang.org>
      212bdd95
    • Brad Fitzpatrick's avatar
      net/http: tighten protocol between Transport.roundTrip and persistConn.readLoop · 7fa98467
      Brad Fitzpatrick authored 
      In debugging the flaky test in #13825, I discovered that my previous
change to tighten and simplify the communication protocol between
Transport.roundTrip and persistConn.readLoop in
https://golang.org/cl/17890 wasn't complete.

This change simplifies it further: the buffered-vs-unbuffered
complexity goes away, and we no longer need to re-try channel reads in
the select case. It was trying to prioritize channels in the case that
two were readable in the select. (it was only failing in the race builder
because the race builds randomize select scheduling)

The problem was that in the bodyless response case we had to return
the idle connection before replying to roundTrip. But putIdleConn
previously both added it to the free list (which we wanted), but also
closed the connection, which made the caller goroutine
(Transport.roundTrip) have two readable cases: pc.closech, and the
response. We guarded against similar conditions in the caller's select
for two readable channels, but such a fix wasn't possible here, and would
be overly complicated.

Instead, switch to unbuffered channels. The unbuffered channels were only
to prevent goroutine leaks, so address that differently: add a "callerGone"
channel closed by the caller on exit, and select on that during any unbuffered
sends.

As part of the fix, split putIdleConn into two halves: a part that
just returns to the freelist, and a part that also closes. Update the
four callers to the variants each wanted.

Incidentally, the connections were closing on return to the pool due
to MaxIdleConnsPerHost (somewhat related: #13801), but this bug
could've manifested for plenty of other reasons.

Fixes #13825

Change-Id: I6fa7136e2c52909d57a22ea4b74d0155fdf0e6fa
Reviewed-on: https://go-review.googlesource.com/18282
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarAndrew Gerrand <adg@golang.org>
      7fa98467
    • Austin Clements's avatar
      runtime/pprof: skip TestStackBarrierProfiling · 59ca8789
      Austin Clements authored 
      This test triggers a large number of usleep(100)s. linux/arm, openbsd,
and solaris have very poor timer resolution on the builders, so
usleep(100) actually gives up the whole scheduling quantum. On Linux
and OpenBSD (and probably Solaris), profiling signals are only
generated when a process completes a whole scheduling quantum, so this
test often gets zero profiling signals and fails.

Until we figure out what to do about this, skip this test on these
platforms.

Updates #13405.

Change-Id: Ica94e4a8ae7a8df3e5a840504f83ee2ec08727df
Reviewed-on: https://go-review.googlesource.com/18252Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
      59ca8789
    • Ian Lance Taylor's avatar
      runtime: fix exit status when killed by signal · 2c67c8c3
      Ian Lance Taylor authored 
      Previously, when a program died because of a SIGHUP, SIGINT, or SIGTERM
signal it would exit with status 2.  This CL fixes the runtime to exit
with a status indicating that the program was killed by a signal.

Change-Id: Ic2982a2562857edfdccaf68856e0e4df532af136
Reviewed-on: https://go-review.googlesource.com/18156Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
      2c67c8c3
    • Ian Lance Taylor's avatar
      runtime: set SIGCONT to _SigNotify + _SigDefault · 81b35117
      Ian Lance Taylor authored 
      Use the current ability to say that we don't do anything with SIGCONT by
default, but programs can catch it using signal.Notify if they want.

Fixes #8953.

Change-Id: I67d40ce36a029cbc58a235cbe957335f4a58e1c5
Reviewed-on: https://go-review.googlesource.com/18185Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      81b35117
    • David Chase's avatar
      cmd/compile: suppress export of Note field within exported bodies · ab5d2bf9
      David Chase authored 
      Added a format option to inhibit output of .Note field in
printing, and enabled that option during export.
Added test.

Fixes #13777.

Change-Id: I739f9785eb040f2fecbeb96d5a9ceb8c1ca0f772
Reviewed-on: https://go-review.googlesource.com/18217Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
      ab5d2bf9
    • Russ Cox's avatar
      net: run all timeout tests in parallel · d731315c
      Russ Cox authored 
      For #10571.

Change-Id: I9a42226078b9c52dbe0c65cb101b5f452233e911
Reviewed-on: https://go-review.googlesource.com/18205Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: default avatarMikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      d731315c
    • Russ Cox's avatar
      misc/cgo/testcshared: print a little more about GOROOT on failure · f2c36df9
      Russ Cox authored 
      For #13789.

Change-Id: I83973298a35afcf55627f0a72223098306a51f4b
Reviewed-on: https://go-review.googlesource.com/18233Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      f2c36df9
    • Russ Cox's avatar
      cmd/dist: wait for pending tests before exiting · 906f9791
      Russ Cox authored 
      When 'go tool dist test' stops, it was intended that it first wait for
pending background tests, like a failed compilation waits for pending
background compiles. But these three lines prevented that.
Fix by deleting them. (The actual loop already contains the correct
logic to avoid running the others and to wait for what's left.)

Change-Id: I4e945495ada903fb0af567910626241bc1c52ba6
Reviewed-on: https://go-review.googlesource.com/18232Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      906f9791
    • Brad Fitzpatrick's avatar
      net/http: relax recently-updated rules and behavior of CloseNotifier · 4b0bc7c3
      Brad Fitzpatrick authored 
      The CloseNotifier implementation and documentation was
substantially changed in https://golang.org/cl/17750 but it was a bit
too aggressive.

Issue #13666 highlighted that in addition to breaking external
projects, even the standard library (httputil.ReverseProxy) didn't
obey the new rules about not using CloseNotifier until the
Request.Body is fully consumed.

So, instead of fixing httputil.ReverseProxy, dial back the rules a
bit. It's now okay to call CloseNotify before consuming the request
body. The docs now say CloseNotifier may wait to fire before the
request body is fully consumed, but doesn't say that the behavior is
undefined anymore. Instead, we just wait until the request body is
consumed and start watching for EOF from the client then.

This CL also adds a test to ReverseProxy (using a POST request) that
would've caught this earlier.

Fixes #13666

Change-Id: Ib4e8c29c4bfbe7511f591cf9ffcda23a0f0b1269
Reviewed-on: https://go-review.googlesource.com/18144Reviewed-by: default avatarRuss Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      4b0bc7c3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7