Runtime netpoll supports at most one read waiter
and at most one write waiter. It's responsibility
of net package to ensure that. Currently windows
implementation allows more than one waiter in Accept.
It leads to "fatal error: netpollblock: double wait".

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

Whether the keys are concatenated or separate (or a mixture) depends on the server.

Fixes #5979.

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

Windows dynamic priority boosting assumes that a process has different types
of dedicated threads -- GUI, IO, computational, etc. Go processes use
equivalent threads that all do a mix of GUI, IO, computations, etc.
In such context dynamic priority boosting does nothing but harm, so turn it off.
In particular, if 2 goroutines do heavy IO on a server uniprocessor machine,
windows rejects to schedule timer thread for 2+ seconds when priority boosting is enabled.
Fixes #5971.

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

The test isn't checking deliberate panics so catching them just makes the code longer.

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

Fixes #5982.

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

Generated by addca.

R=gobot
CC=golang-dev
https://golang.org/cl/12419043

Update #5764

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

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

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

This CL makes IPAddr, UDPAddr and TCPAddr implement sockaddr
interface, UnixAddr is already sockaddr interface compliant, and
reduces unnecessary conversions between net.Addr, net.sockaddr and
syscall.Sockaddr.

This is in preparation for runtime-integrated network pollster for BSD
variants.

Update #5199

R=golang-dev, dave, bradfitz
CC=golang-dev
https://golang.org/cl/12010043

Update #3610
Update #5267
Update #5707

R=golang-dev, bradfitz, dave, fvbommel
CC=golang-dev
https://golang.org/cl/11958043

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

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

This was missed in c3b45d0dc5c0

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

Also, add a meaningful error message when an encoding which
can't be parsed is found.

Fixes #5801.

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

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

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

I am really bad at this. Didn't hg add this file.

TBR=bradfitz
CC=golang-dev
https://golang.org/cl/12372043

TBR=bradfitz
CC=golang-dev
https://golang.org/cl/12369043

Fixes #5822.
Will no doubt cause other problems, but Apple has forced our hand.

R=golang-dev, bradfitz, khr
CC=golang-dev
https://golang.org/cl/12350044

Also add \n to error message.

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

Checking this condition helped me find the arm problem last night.

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

cmd/api is a tool to prevent the Go developers from breaking
the Go 1 API promise. It has no utility to end users and
doesn't run on arbitrary packages (it's always been full of
hacks for its bespoke type checker to work on the standard
library)

Robert's in-progress rewrite depends on the go.tools repo for
go/types, so we won't be able to ship this tool later
anyway. Just remove it from binary distributions.

A future change to run.bash can conditionally build & run
cmd/api, perhaps automatically fetching go/types if
necessary. I assume people don't want to vendor go/types into
a private gopath just for cmd/api.

I will need help with run.bat.

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

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

R=r, adg, bradfitz
CC=golang-dev
https://golang.org/cl/12312043

Includes deleting some unused items.

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

It's okay to preempt at ordinary function calls because
compilers arrange that there are no live registers to save
on entry to the function call.

The software floating point routines are function calls
masquerading as individual machine instructions. They are
expected to keep all the registers intact. In particular,
they are expected not to clobber all the floating point
registers.

The floating point registers are kept per-M, because they
are not live at non-preemptive goroutine scheduling events,
and so keeping them per-M reduces the number of 132-byte
register blocks we are keeping in memory.

Because they are per-M, allowing the goroutine to be
rescheduled during software floating point simulation
would mean some other goroutine could overwrite the registers
or perhaps the goroutine would continue running on a different
M entirely.

Disallow preemption during the software floating point
routines to make sure that a function full of floating point
instructions has the same floating point registers throughout
its execution.

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/12298043

Per suggestion from Russ in February. Then strings.IndexByte
can be implemented in terms of the shared code in pkg runtime.

Update #3751

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

Previously if a path was set manually without a leading /, String()
would not insert the slash when writing its output. This would lead
to situations where a URL that should be http://www.google.com/search
is output as http://www.google.comsearch

Fixes #5927.

R=golang-dev, bradfitz, rsc, 0xjnml
CC=golang-dev
https://golang.org/cl/11698045

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

Generated by addca.

R=gobot
CC=golang-dev
https://golang.org/cl/12291043

I used just enough of the data provided by Matt in Issue 5915 to trigger
issue 5915. As luck would have it, using slightly less of it triggered
issue 5962.

Fixes #5915.
Fixes #5962.

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

Fixes #3033

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

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

I always forget which package has it.

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

Also move chatty recent additions to -v -v.

For what it's worth:

$ go build -o /dev/null -ldflags -v cmd/go
...
 0.87 pclntab=1110836 bytes, funcdata total 69700 bytes
...
$

This broke the ELF builds last time because I tried to dedup
the funcdata in case the same funcdata was pointed at by
multiple functions. That doesn't currently happen, so I've
removed that test.

If we start doing bitmap coalescing we'll need to figure out
how to measure the size more carefully, but I think at that
point the bitmaps will be an extra indirection away from the
funcdata anyway, so the dedup I used before wouldn't help.

R=ken2
CC=golang-dev
https://golang.org/cl/12269043

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

This allows to at least determine goroutine "identity".
Now it looks like:
goroutine 12 [running]:
        goroutine running on other thread; stack unavailable
created by testing.RunTests
        src/pkg/testing/testing.go:440 +0x88e

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

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

We see timeouts in these tests on some platforms,
but not on the others.  The hypothesis is that
the problematic platforms are slow uniprocessors.
Stack traces do not suggest that the process
is completely hang, and it is able to schedule
the alarm goroutine. And if it actually hangs,
we still will be able to detect that.

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