Brad Fitzpatrick [Wed, 7 Aug 2013 01:33:03 +0000 (18:33 -0700)]
net/http: treat HEAD requests like GET requests
A response to a HEAD request is supposed to look the same as a
response to a GET request, just without a body.
HEAD requests are incredibly rare in the wild.
The Go net/http package has so far treated HEAD requests
specially: a Write on our default ResponseWriter returned
ErrBodyNotAllowed, telling handlers that something was wrong.
This was to optimize the fast path for HEAD requests, but:
1) because HEAD requests are incredibly rare, they're not
worth having a fast path for.
2) Letting the http.Handler handle but do nop Writes is still
very fast.
3) this forces ugly error handling into the application.
e.g. https://code.google.com/p/go/source/detail?r=6f596be7a31e
and related.
4) The net/http package nowadays does Content-Type sniffing,
but you don't get that for HEAD.
5) The net/http package nowadays does Content-Length counting
for small (few KB) responses, but not for HEAD.
6) ErrBodyNotAllowed was useless. By the time you received it,
you had probably already done all your heavy computation
and I/O to calculate what to write.
So, this change makes HEAD requests like GET requests.
We now count content-length and sniff content-type for HEAD
requests. If you Write, it doesn't return an error.
If you want a fast-path in your code for HEAD, you have to do
it early and set all the response headers yourself. Just like
before. If you choose not to Write in HEAD requests, be sure
to set Content-Length if you know it. We won't write
"Content-Length: 0" because you might've just chosen to not
write (or you don't know your Content-Length in advance).
Rob Pike [Tue, 6 Aug 2013 22:38:46 +0000 (08:38 +1000)]
fmt: fix up zero padding
If the padding is huge, we crashed by blowing the buffer. That's easy: make sure
we have a big enough buffer by allocating in problematic cases.
Zero padding floats was just wrong in general: the space would appear in the
middle.
Rob Pike [Tue, 6 Aug 2013 20:49:11 +0000 (06:49 +1000)]
runtime: use correct types for maxstring and concatstring
Updates #6046.
This CL just does maxstring and concatstring. There are other functions
to fix but doing them a few at a time will help isolate any (unlikely)
breakages these changes bring up in architectures I can't test
myself.
Brad Fitzpatrick [Tue, 6 Aug 2013 19:04:08 +0000 (12:04 -0700)]
os: fix plan9 build
I broke it with the darwin getwd attrlist stuff (0583e9d36dd).
plan9 doesn't have syscall.ENOTSUP.
It's in api/go1.txt as a symbol always available (not context-specific):
pkg syscall, const ENOTSUP Errno
... but plan9 isn't considered by cmd/api, so it only looks
universally available. Alternatively, we could add a fake ENOTSUP
to plan9, but they were making efforts earlier to clean their
syscall package, so I'd prefer not to dump more in it.
This change replaces the hard-coded switch on compression method
in zipfile reader and writer with a map into which users can
register compressors and decompressors in their init()s.
Mikio Hara [Tue, 6 Aug 2013 15:25:23 +0000 (00:25 +0900)]
syscall: fix IPv6 wrong network mask on latest FreeBSD
Looks like latest FreeBSD doesn't set address family identifer
for RTAX_NETMASK stuff; probably RTAX_GENMASK too, not confirmed.
This CL tries to identify address families by using the length of
each socket address if possible.
Mikio Hara [Tue, 6 Aug 2013 14:42:33 +0000 (23:42 +0900)]
net: separate pollster initialization from network file descriptor allocation
Unlike the existing net package own pollster, runtime-integrated
network pollster on BSD variants, actually kqueue, requires a socket
that has beed passed to syscall.Listen previously for a stream
listener.
This CL separates pollDesc.Init (actually runtime_pollOpen) from newFD
to allow control of each state of sockets and adds init method to netFD
instead. Upcoming CLs will rearrange the call order of runtime-integrated
pollster and syscall functions like the following;
- For dialers that open active connections, runtime_pollOpen will be
called in between syscall.Bind and syscall.Connect.
- For stream listeners that open passive stream connections,
runtime_pollOpen will be called just after syscall.Listen.
- For datagram listeners that open datagram connections,
runtime_pollOpen will be called just after syscall.Bind.
This is in preparation for runtime-integrated network pollster for BSD
variants.
Rob Pike [Tue, 6 Aug 2013 11:49:03 +0000 (21:49 +1000)]
runtime: change int32 to intgo in findnull and findnullw
Update #6046.
This CL just does findnull and findnullw. There are other functions
to fix but doing them a few at a time will help isolate any (unlikely)
breakages these changes bring up in architectures I can't test
myself.
Dmitriy Vyukov [Tue, 6 Aug 2013 09:38:44 +0000 (13:38 +0400)]
runtime: use gcpc/gcsp during traceback of goroutines in syscalls
gcpc/gcsp are used by GC in similar situation.
gcpc/gcsp are also more stable than gp->sched,
because gp->sched is mutated by entersyscall/exitsyscall
in morestack and mcall. So it has higher chances of being inconsistent.
Also, rename gcpc/gcsp to syscallpc/syscallsp.
This is the same as reverted change 12250043
with save marked as textflag 7.
The problem was that if save calls morestack,
then subsequent lessstack spoils g->sched.pc/sp.
And that bad values were remembered in g->syscallpc/sp.
Entersyscallblock had the same problem,
but it was never triggered to date.
Russ Cox [Mon, 5 Aug 2013 23:49:02 +0000 (19:49 -0400)]
runtime/pprof: test multithreaded profile, remove OS X workarounds
This means that pprof will no longer report profiles on OS X.
That's unfortunate, but the profiles were often wrong and, worse,
it was difficult to tell whether the profile was wrong or not.
The workarounds were making the scheduler more complex,
possibly caused a deadlock (see issue 5519), and did not actually
deliver reliable results.
It may be possible for adventurous users to apply a patch to
their kernels to get working results, or perhaps having no results
will encourage someone to do the work of creating a profiling
thread like on Windows. Issue 6047 has details.
Fixes #5519.
Fixes #6047.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/12429045
Keith Randall [Mon, 5 Aug 2013 20:24:33 +0000 (13:24 -0700)]
cmd/gc: get rid of redundant slice bound check.
For normal slices a[i:j] we're generating 3 bounds
checks: j<={len(string),cap(slice)}, j<=j (!), and i<=j.
Somehow snuck in as part of the [i:j:k] implementation
where the second check does something.
Remove the second check when we don't need it.
R=rsc, r
CC=golang-dev
https://golang.org/cl/12311046
««« original CL description
runtime: use gcpc/gcsp during traceback of goroutines in syscalls
gcpc/gcsp are used by GC in similar situation.
gcpc/gcsp are also more stable than gp->sched,
because gp->sched is mutated by entersyscall/exitsyscall
in morestack and mcall. So it has higher chances of being inconsistent.
Also, rename gcpc/gcsp to syscallpc/syscallsp.
Dmitriy Vyukov [Mon, 5 Aug 2013 18:58:02 +0000 (22:58 +0400)]
runtime: remove singleproc var
It was needed for the old scheduler,
because there temporary could be more threads than gomaxprocs.
In the new scheduler gomaxprocs is always respected.
Dmitriy Vyukov [Mon, 5 Aug 2013 18:55:54 +0000 (22:55 +0400)]
runtime: use gcpc/gcsp during traceback of goroutines in syscalls
gcpc/gcsp are used by GC in similar situation.
gcpc/gcsp are also more stable than gp->sched,
because gp->sched is mutated by entersyscall/exitsyscall
in morestack and mcall. So it has higher chances of being inconsistent.
Also, rename gcpc/gcsp to syscallpc/syscallsp.
Adam Langley [Mon, 5 Aug 2013 18:23:32 +0000 (14:23 -0400)]
crypto: include hash number in panic message.
In the event that code tries to use a hash function that isn't compiled
in and panics, give the developer a fighting chance of figuring out
which hash function it needed.
Dmitriy Vyukov [Sun, 4 Aug 2013 19:31:23 +0000 (23:31 +0400)]
net: fix concurrent Accept on windows
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".
Dmitriy Vyukov [Sun, 4 Aug 2013 10:08:13 +0000 (14:08 +0400)]
runtime: disable dynamic priority boosting on windows
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.
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.
Brad Fitzpatrick [Fri, 2 Aug 2013 17:19:52 +0000 (10:19 -0700)]
misc/dist: don't ship cmd/api
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.
Russ Cox [Fri, 2 Aug 2013 00:07:01 +0000 (20:07 -0400)]
runtime: disable preemption during software fp routines
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
Scott Ferguson [Thu, 1 Aug 2013 22:52:56 +0000 (15:52 -0700)]
net/url: prepend slash to path in String()
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
Pieter Droogendijk [Thu, 1 Aug 2013 22:20:01 +0000 (15:20 -0700)]
compress/flate: Fixed two panics on bad data
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.
Russ Cox [Thu, 1 Aug 2013 16:58:27 +0000 (12:58 -0400)]
cmd/ld: report pclntab, funcdata sizes in 6l -v output
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.
Dmitriy Vyukov [Thu, 1 Aug 2013 15:28:38 +0000 (19:28 +0400)]
runtime: print "created by" for running goroutines in traceback
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
Dmitriy Vyukov [Thu, 1 Aug 2013 14:25:36 +0000 (18:25 +0400)]
runtime: make new tests shorter in short mode
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
1) Explain a[i] and a[i:j] where a is of type *A as
shortcut for (*a)[i] and (*a)[i:j], respectively.
2) Together with 1), because len() of nil slices is
well defined, there's no need to special case nil
operands anymore.
3) The result of indexing or slicing a constant string
is always a non-constant byte or string value.
4) The result of slicing an untyped string is a value
of type string.
5) If the operand of a valid slice a[i:j] is nil (i, j
must be 0 for it to be valid - this already follows
from the in-range rules), the result is a nil slice.
Fixes #4913.
Fixes #5951.
R=r, rsc, iant, ken
CC=golang-dev
https://golang.org/cl/12198043