Skip to content

G
go
Switch branch/tag
  1. 25 Mar, 2014 10 commits
    • Ian Lance Taylor's avatar
      runtime: accurately record whether heap memory is reserved · 4ebfa831
      Ian Lance Taylor authored 
      The existing code did not have a clear notion of whether
memory has been actually reserved.  It checked based on
whether in 32-bit mode or 64-bit mode and (on GNU/Linux) the
requested address, but it confused the requested address and
the returned address.

LGTM=rsc
R=rsc, dvyukov
CC=golang-codereviews, michael.hudson
https://golang.org/cl/79610043
      4ebfa831
    • Brad Fitzpatrick's avatar
      net/http: don't re-use Transport connections if we've seen an EOF · cc2c5fc3
      Brad Fitzpatrick authored 
      This the second part of making persistent HTTPS connections to
certain servers (notably Amazon) robust.

See the story in part 1: https://golang.org/cl/76400046/

This is the http Transport change that notes whether our
net.Conn.Read has ever seen an EOF. If it has, then we use
that as an additional signal to not re-use that connection (in
addition to the HTTP response headers)

Fixes #3514

LGTM=rsc
R=agl, rsc
CC=golang-codereviews
https://golang.org/cl/79240044
      cc2c5fc3
    • Brad Fitzpatrick's avatar
      crypto/tls: make Conn.Read return (n, io.EOF) when EOF is next in buffer · f61f18d6
      Brad Fitzpatrick authored 
      Update #3514

An io.Reader is permitted to return either (n, nil)
or (n, io.EOF) on EOF or other error.

The tls package previously always returned (n, nil) for a read
of size n if n bytes were available, not surfacing errors at
the same time.

Amazon's HTTPS frontends like to hang up on clients without
sending the appropriate HTTP headers. (In their defense,
they're allowed to hang up any time, but generally a server
hangs up after a bit of inactivity, not immediately.) In any
case, the Go HTTP client tries to re-use connections by
looking at whether the response headers say to keep the
connection open, and because the connection looks okay, under
heavy load it's possible we'll reuse it immediately, writing
the next request, just as the Transport's always-reading
goroutine returns from tls.Conn.Read and sees (0, io.EOF).

But because Amazon does send an AlertCloseNotify record before
it hangs up on us, and the tls package does its own internal
buffering (up to 1024 bytes) of pending data, we have the
AlertCloseNotify in an unread buffer when our Conn.Read (to
the HTTP Transport code) reads its final bit of data in the
HTTP response body.

This change makes that final Read return (n, io.EOF) when
an AlertCloseNotify record is buffered right after, if we'd
otherwise return (n, nil).

A dependent change in the HTTP code then notes whether a
client connection has seen an io.EOF and uses that as an
additional signal to not reuse a HTTPS connection. With both
changes, the majority of Amazon request failures go
away. Without either one, 10-20 goroutines hitting the S3 API
leads to such an error rate that empirically up to 5 retries
are needed to complete an API call.

LGTM=agl, rsc
R=agl, rsc
CC=golang-codereviews
https://golang.org/cl/76400046
      f61f18d6
    • Ian Lance Taylor's avatar
      runtime: change nproc local variable to uint32 · 8de04c78
      Ian Lance Taylor authored 
      The nproc and ndone fields are uint32.  This makes the type
consistent.

LGTM=minux.ma
R=golang-codereviews, minux.ma
CC=golang-codereviews
https://golang.org/cl/79340044
      8de04c78
    • Nigel Tao's avatar
      database/sql: add "defer rows.Close()" to the example code. · 50ca1a52
      Nigel Tao authored 
      Strictly speaking, it's not necessary in example_test.go, as the
Rows.Close docs say that "If Next returns false, the Rows are closed
automatically". However, if the for loop breaks or returns early, it's
not obvious that you'll leak unless you explicitly call Rows.Close.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews, rsc
https://golang.org/cl/79330043
      50ca1a52
    • Russ Cox's avatar
      runtime: use VEH, not SEH, for windows/386 exception handling · 3750904a
      Russ Cox authored 
      Structured Exception Handling (SEH) was the first way to handle
exceptions (memory faults, divides by zero) on Windows.
The S might as well stand for "stack-based": the implementation
interprets stack addresses in a few different ways, and it gets
subtly confused by Go's management of stacks. It's also something
that requires active maintenance during cgo switches, and we've
had bugs in that maintenance in the past.

We have recently come to believe that SEH cannot work with
Go's stack usage. See http://golang.org/issue/7325 for details.

Vectored Exception Handling (VEH) is more like a Unix signal
handler: you set it once for the whole process and forget about it.

This CL drops all the SEH code and replaces it with VEH code.
Many special cases and 7 #ifdefs disappear.

VEH was introduced in Windows XP, so Go on windows/386 will
now require Windows XP or later. The previous requirement was
Windows 2000 or later. Windows 2000 immediately preceded
Windows XP, so Windows 2000 is the only affected version.
Microsoft stopped supporting Windows 2000 in 2010.
See http://golang.org/s/win2000-golang-nuts for details.

Fixes #7325.

LGTM=alex.brainman, r
R=golang-codereviews, alex.brainman, stephen.gutekanst, dave
CC=golang-codereviews, iant, r
https://golang.org/cl/74790043
      3750904a
    • Russ Cox's avatar
      time: add comment explaining rejection of years outside [0000,9999] · 3b27343c
      Russ Cox authored 
      This has come up twice now. Redirect future questions
to the explanation in the issue tracker.

LGTM=iant, r
R=r, iant
CC=golang-codereviews
https://golang.org/cl/79550043
      3b27343c
    • Rob Pike's avatar
      math/cmplx: define Pow(0, x) for problematic values of x. · a9014ba4
      Rob Pike authored 
      Currently it's always zero, but that is inconsistent with math.Pow
and also plain wrong.
This is a proposal for how it should be defined.
Fixes #7583.

LGTM=rsc
R=golang-codereviews, iant, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/76940044
      a9014ba4
    • Rob Pike's avatar
      regexp/syntax: document the upper limit of n in x{n} · 929ee59f
      Rob Pike authored 
      Fixes #7252.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/77990044
      929ee59f
    • Rob Pike's avatar
      regexp: document that it is linear in the input size. · c790b029
      Rob Pike authored 
      Fixes #7488.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/78050043
      c790b029
  3. 24 Mar, 2014 6 commits
  5. 23 Mar, 2014 3 commits
  7. 22 Mar, 2014 2 commits
  9. 21 Mar, 2014 4 commits
  11. 20 Mar, 2014 10 commits
  13. 19 Mar, 2014 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7