Previously, a set of standard signals would be handled automatically via
an init() function, however that made the package difficult to use in
packages in which an HTTP server would only be spawned some of the times
(perhaps keyed on an environment variable or flag). Now, signals must be
registered manually.
By default, the top-level "goji" package automatically registers
signals with graceful, so this will result in no behavior changes for
most people.
Fixes#35.
Many common panic values, e.g. nil pointer dereferences, don't print
very well under "%#v", emitting something like
"runtime.errorCString{cstr:0x54b2a4}" or similar.
If WriteHeader is called multiple times on a http.ResponseWriter, the
first status is the one that is used, not the last. Fix the wrapped
writer to reflect this fact.
For whatever reason, Go insisted on loading rm.sm[i] in several chunks,
even though it could be loaded in a single 64-bit block. Instead, let's
reorder our loads to minimize the amount of memory we're uselessly
moving around.
This gives us about a 15% perf boost in
github.com/julienschmidt/go-http-routing-benchmark's
BenchmarkGoji_StaticAll, and questionable benefits (i.e., not
distinguishable from noise but certainly no worse) on Goji's own
benchmarks.
This eliminates the race condition mentioned in a54c913a by forbidding
duplicate binds to the same socket (well, at least in the sense that
attempting to do so will *always* result in an error instead of
nondeterministically resulting in an error).
This fixes a race condition between package bind and the garbage
collector, where if the garbage collector ran between einhornInit and
einhornBind, bind would fatal with the error "dup: bad file descriptor"
The core of the bug is that Go's os.File uses runtime.SetFinalizer to
register a callback to close the underlying file descriptor an os.File
points at when the os.File itself is being garbage collected. However,
the Einhorn initialization code in bind, in the process of ensuring that
every Einhorn-passed socket had CloseOnExec set on it, allocated
os.File's pointing at each of these passed file descriptors, but did not
keep references to these os.File's, allowing them to be garbage
collected. Subsequently, if you attempted to bind one of these sockets,
you'd find that it was no longer open.
This is the simplest fix to the bug, which is to only allocate an
os.File when we actually attempt to bind the socket. Note that there's
still a race condition here if you attempt to bind the same file
descriptor twice, since a GC between the two binds will likely cause the
file to be collected. Fortunately, that one can be worked around by
simply not allowing such silly behavior :). Another patch that makes
this more clear will follow.
Closes#29.
First draft, suggestions for improvements are welcome. The snippet
should serve as the idiomatic guide on how to get all pages for a given
resource (a common use case without an obvious solution, hence the docs
can be very helpful).
Change the per-process nonce part of the request ID from 8 characters to
10, and wrap the entire thing in a retry loop so you can never get an
"unlucky" panic. I know this will "never" happen in practice, but it
doesn't hurt to make sure we never, ever have any collisions, and never,
ever have any runtime panics.
It's also worth documenting the math ("math") I used to calculate the
numbers here.