With this in place, a TLS server is capable of selecting the correct
certificate based on the client's ServerNameIndication extension.

The need to call Config.BuildNameToCertificate is unfortunate, but
adding a sync.Once to the Config structure made it uncopyable and I
felt that was too high a price to pay. Parsing the leaf certificates
in each handshake was too inefficient to consider.

R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5151048

Implement a locking model based on the current linux model - a
tri-state mutex with active spinning, passive spinning and sleeping.

R=golang-dev, dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4974043

R=r
CC=golang-dev
https://golang.org/cl/5235043

t.ns was hanging after recent changes.

R=gri, rsc
CC=golang-dev
https://golang.org/cl/5237044

Was never working correctly when executing from the command-line.

R=r
CC=golang-dev
https://golang.org/cl/5236042

R=r
CC=golang-dev
https://golang.org/cl/5235042

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5237041

R=r, rsc, alex.brainman
CC=golang-dev
https://golang.org/cl/5234041

Also: Fewer calls to flush for faster processing (once per identifier
or error instead of once per token).

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5236041

I accidentally left it off of https://golang.org/cl/5132048/.

R=r
CC=golang-dev
https://golang.org/cl/5202042

FileSet deserialization (Read) uses its own instance of a gob decoder.
If the FileSet data may be followed by other data on the reader, Read
may consume too much data that is lost unless the reader implements
ReadByte.

Also: Minor internal refactoring for symmetry.

R=r
CC=golang-dev
https://golang.org/cl/5233041

Also: Minor refactoring for cleanliness and symmetry.

Fixes #2286.

R=r
CC=golang-dev
https://golang.org/cl/5232041

This is a semantic but no API change. It is a cleaner
implementation of pure filtering. Applications that
need function bodies stripped can easily do this them-
selves.

R=rsc
CC=golang-dev
https://golang.org/cl/5206046

Removed the URL form parameter "f=text" in favor of a more
flexible mode parameter "m" which now accepts a list of mode
flags as documented in doc.go.

Fixes #1784.

R=rsc
CC=golang-dev
https://golang.org/cl/5227041

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5231041

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5207044

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/5208042

R=golang-dev, rsc, dsymonds
CC=golang-dev
https://golang.org/cl/5209045

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5211045

This CL introduces the go.Example type and go.Examples functions that
are used to represent and extract code samples from Go source.

They should be of the form:

// Output of this function.
func ExampleFoo() {
        fmt.Println("Output of this function.")
}

It also modifies godoc to read example code from _test.go files,
and include them in the HTML output with JavaScript-driven toggles.

It also implements testing of example functions with gotest.
The stdout/stderr is compared against the output comment on the
function.

This CL includes examples for the sort.Ints function and the
sort.SortInts type. After patching this CL in and re-building go/doc
and godoc, try
        godoc -http=localhost:6060
and visit http://localhost:6060/pkg/sort/

R=gri, r, rsc
CC=golang-dev
https://golang.org/cl/5137041

Allows passing extra fds to the child process.

Fixes #2329

R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/5162050

Fixes #2336.

R=golang-dev, dsymonds, rsc
CC=golang-dev
https://golang.org/cl/5222042

R=golang-dev, bradfitz, dsymonds, gri
CC=golang-dev
https://golang.org/cl/5223043

See discussion at https://groups.google.com/d/topic/golang-dev/RAKiqi44GEU/discussion

R=golang-dev, bradfitz, dvyukov, rogpeppe, r, r, borman
CC=golang-dev
https://golang.org/cl/5071044

R=golang-dev, gri
CC=golang-dev, miki.tebeka
https://golang.org/cl/5225042

Linux/amd64, 2 x Intel Xeon E5620, 8 HT cores, 2.40GHz
benchmark                    old ns/op    new ns/op    delta
BenchmarkFinalizer              420.00       261.00  -37.86%
BenchmarkFinalizer-2            985.00       201.00  -79.59%
BenchmarkFinalizer-4           1077.00       244.00  -77.34%
BenchmarkFinalizer-8           1155.00       180.00  -84.42%
BenchmarkFinalizer-16          1182.00       184.00  -84.43%

BenchmarkFinalizerRun          2128.00      1378.00  -35.24%
BenchmarkFinalizerRun-2        1655.00      1418.00  -14.32%
BenchmarkFinalizerRun-4        1634.00      1522.00   -6.85%
BenchmarkFinalizerRun-8        2213.00      1581.00  -28.56%
BenchmarkFinalizerRun-16       2424.00      1599.00  -34.03%

Darwin/amd64, Intel L9600, 2 cores, 2.13GHz
benchmark                    old ns/op    new ns/op    delta
BenchmarkChanCreation          1451.00       926.00  -36.18%
BenchmarkChanCreation-2        3124.00      1412.00  -54.80%
BenchmarkChanCreation-4        6121.00      2628.00  -57.07%

BenchmarkFinalizer              684.00       420.00  -38.60%
BenchmarkFinalizer-2          11195.00       398.00  -96.44%
BenchmarkFinalizer-4          15862.00       654.00  -95.88%

BenchmarkFinalizerRun          2025.00      1397.00  -31.01%
BenchmarkFinalizerRun-2        3920.00      1447.00  -63.09%
BenchmarkFinalizerRun-4        9471.00      1545.00  -83.69%

R=golang-dev, cw, rsc
CC=golang-dev
https://golang.org/cl/4963057

The malloc sample trigger was not being set in a
new m, so the first allocation in each new m - the
goroutine structure - was being sampled with
probability 1 instead of probability sizeof(G)/rate,
an oversampling of about 5000x for the default
rate of 1 MB.  This bug made pprof graphs show
far more G allocations than there actually were.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5224041

Fixes #2337.
Unfortunate sequence of events is:
1. maxcpu=2, mcpu=1, grunning=1
2. starttheworld creates an extra M:
   maxcpu=2, mcpu=2, grunning=1
4. the goroutine calls runtime.GOMAXPROCS(1)
   maxcpu=1, mcpu=2, grunning=1
5. since it sees mcpu>maxcpu, it calls gosched()
6. schedule() deschedules the goroutine:
   maxcpu=1, mcpu=1, grunning=0
7. schedule() call getnextandunlock() which
   fails to pick up the goroutine again,
   because canaddcpu() fails, because mcpu==maxcpu
8. then it sees that grunning==0,
   reports deadlock and terminates

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5191044

R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/5201042

R=rsc, jp, hectorchu
CC=golang-dev
https://golang.org/cl/4962051

therefore unlikely that there is a good use for its string version
LastBoundaryInString. Yet, the implemenation of this method would complicate
things a bit as it would require the introduction for another interface and
some duplication of code. Removing it seems a better choice.

R=r
CC=golang-dev
https://golang.org/cl/5182044

R=bradfitz
CC=golang-dev
https://golang.org/cl/5208041

R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/5204041

binary.BenchmarkPutUvarint32 20000000	 85.6 ns/op
binary.BenchmarkPutUvarint64 10000000	299   ns/op

R=rsc
CC=golang-dev
https://golang.org/cl/5148049

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5190045

R=golang-dev, rsc, r
CC=golang-dev
https://golang.org/cl/5181045

Major changes between hybi-08 and hybi-13
- hybi-08 uses Sec-WebSocket-Origin, but hybi-13 uses Origin
- hybi-13 introduces new close status codes.

hybi-17 spec (editorial changes of hybi-13) mentions
- if a server doesn't support the requested version, it MUST respond
  with Sec-WebSocket-Version headers containing all available versions.
- client MUST close the connection upon receiving a masked frame
- server MUST close the connection upon receiving a non-masked frame
note that hybi-17 still uses "Sec-WebSocket-Version: 13"

see http://code.google.com/p/pywebsocket/wiki/WebSocketProtocolSpec
for changes between spec drafts.

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/5147043

R=adg, cw, lvd
CC=golang-dev
https://golang.org/cl/5168046

of methods.

R=r, mpvl
CC=golang-dev
https://golang.org/cl/5166045

R=rsc, r
CC=golang-dev
https://golang.org/cl/5192043