1. 09 Feb, 2017 2 commits
  2. 06 Feb, 2017 2 commits
  3. 03 Feb, 2017 1 commit
  4. 01 Feb, 2017 2 commits
  5. 14 Jan, 2017 1 commit
  6. 13 Jan, 2017 3 commits
  7. 10 Jan, 2017 3 commits
  8. 09 Jan, 2017 6 commits
  9. 08 Jan, 2017 1 commit
    • Lucas Bremgartner's avatar
      x/net/bpf: cleanup TestAsmDisasm · da2b4fa2
      Lucas Bremgartner authored
      The "fake" jump conditions as well as the LoadExtension instructions
      are now disassembled correctly. Therefore the workaround to reassemble
      the disassembly is no longer necessary.
      
      This simplification was annonced already in golang/go#18470.
      
      Result of `go test -cover .` stays the same with this simplification.
      
      $ go test -cover golang.org/x/net/bpf
      ok  	golang.org/x/net/bpf	0.495s	coverage: 92.3% of statements
      
      Change-Id: I3f9eb46148287c76059437b773b80c4c99eb5b53
      Reviewed-on: https://go-review.googlesource.com/34951
      Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMatt Layher <mdlayher@gmail.com>
      da2b4fa2
  10. 07 Jan, 2017 3 commits
  11. 06 Jan, 2017 3 commits
  12. 05 Jan, 2017 1 commit
  13. 02 Jan, 2017 1 commit
    • Meir Fischer's avatar
      http2: remove unnecessary TODO for trailer keys allocation · 69d4b8aa
      Meir Fischer authored
      strings.Join has two allocations:
      (1) []byte intermediate
      (2) final string conversion
      The comma-separated keys are ultimately stored in hpack.HeaderField.Value
      as a string so (2) is not wasteful. Because strings.Join is used so heavily
      I assume its implementation is optimal - (1) is necessary.
      Therefore, short of refactoring hpack.HeaderField's Value type, the status quo
      seems optimal.
      
      This TODO appears to have been copy-pasted from net/http/transfer.go
      However, the two cases are different. transfer.go has two allocations
      in addition to strings.Join: concatenation with literals and converting
      string to bytes in io.WriteString.
      
      Change-Id: I292203a6535dd2774f5bf45e7280b89aabb5d78d
      Reviewed-on: https://go-review.googlesource.com/34626Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      69d4b8aa
  14. 29 Dec, 2016 1 commit
  15. 15 Dec, 2016 7 commits
  16. 13 Dec, 2016 1 commit
    • Brad Fitzpatrick's avatar
      context: deflake tests under Go 1.6 · cfae461c
      Brad Fitzpatrick authored
      The context tests were flaky under Go 1.6 on Windows. Make them
      slower, but make up for the slowness by parallelizing them.
      
      These tests don't run on Go 1.7+ in the subrepo. They were deflaked in
      the standard library's context in Go 1.7.
      
      Updates golang/go#11811
      
      Change-Id: I8dc8d9e13e72e87b4444e92d2316dd95bd7d066d
      Reviewed-on: https://go-review.googlesource.com/34288
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      cfae461c
  17. 10 Dec, 2016 2 commits
    • Brad Fitzpatrick's avatar
      http2: speed up TestTransportFlowControl in short mode · b1a2d6e8
      Brad Fitzpatrick authored
      Updates golang/go#18273
      
      Change-Id: I2e7589d070a2953972bc8456d572edd616525266
      Reviewed-on: https://go-review.googlesource.com/34271
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
      b1a2d6e8
    • Tom Bergan's avatar
      http2: don't flush a stream's write queue in sc.resetStream · 3d9a20a7
      Tom Bergan authored
      resetStream(st) queues a RST_STREAM frame and then calls closeStream(st).
      Unfortunately, closeStream(st) flushes any writes pending on st, which
      can drop the RST_STREAM that was just queued. (If we are lucky, the
      RST_STREAM will fit in the send buffer and won't be dropped, however,
      if we are unlucky the RST_STREAM will be dropped.)
      
      I fixed this bug by removing closeStream(st) from resetStream. Instead,
      closeStream happens after the RST_STREAM frame is written. This is a more
      direct implementation of the diagram in RFC 7540 Section 5.1, which says
      that a stream does not transition to "closed" until after the RST_STREAM
      has been sent.
      
      A side-effect is that the stream may stay open for longer than it did
      previously (since it won't close until *after* the RST_STREAM frame is
      actually written). Situations like the following are a problem:
      
      - Client sends a DATA frame that exceeds its flow-control window
      - Server returns streamError(ErrCodeFlowControl) from processData
      - RST_STREAM is queued behind other frames
      - Server process the request body and releases flow-control
      - Client sends another DATA frame, this one fits in the flow-control
        window. Server should NOT process this frame.
      
      To avoid the above problem, we set a bool st.resetQueued=true when
      RST_STREAM is queued, then ignore all future incoming HEADERS and DATA
      frames on that stream.
      
      I also removed st.sentReset and st.gotReset, which were used to ignore
      frames after RST_STREAM is sent. Now we just check if the stream is closed.
      
      Fixes golang/go#18111
      
      Change-Id: Ieb7c848989431add5b7d95f40d6d91db7edc4980
      Reviewed-on: https://go-review.googlesource.com/34238Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      3d9a20a7