Date | Commit message (Collapse) |
|
There's actually no reason we can't have these methods
in Rainbows::Configurator where it's easier to document
nowadays.
|
|
IO#trysendfile does not raise exceptions for common EAGAIN
errors, making it far less expensive to use with the following
concurrency models:
* Coolio
* CoolioFiberSpawn
* Revactor
* FiberSpawn
* FiberPool
This requires the new sendfile 1.1.0 RubyGem and removes support
for the sendfile 1.0.0. All sendfile users must upgrade or be
left without sendfile(2) support. IO#sendfile behaves the same
if you're using a multi-threaded concurrency option, but we
don't detect nor use it unless IO#trysendfile exists.
|
|
We were needlessly allocating objects even when using yield.
|
|
We want to use the singleton methods in Kgio to reduce
conditionals.
|
|
The WebSocket protocol is still undergoing changes and unused.
We won't waste time supporting it until it's finalized and
doesn't break HTTP.
|
|
Easier just to use an instance variable
|
|
Rack::Utils::HeaderHash is still very expensive in Rack 1.2,
especially for simple things that we want to run as fast as
possible with minimal interference. HeaderHash is unnecessary
for most requests that do not send Content-Range in responses.
|
|
Unique method names makes it easier to follow code and determine
where our methods come from.
|
|
Some middlewares require the Rack env to be preserved all
the way through to close, so we'll ensure all request models
preserve it.
We also need to better response body wrappers/proxies always get
fired properly when returning. IO.copy_stream and "sendfile"
gem users could hit cases where wrappers did not fire properly.
|
|
Some applications never need TeeSocket, and we don't have
to worry about thread-safety with Revactor.
|
|
This should make things easier on the eyes.
|
|
Due to the synchronous nature of Revactor, we can
be certain sendfile won't overstep the userspace
output buffering done by Rev.
|
|
Proxying regular Ruby IO objects while Revactor is in use is
highly suboptimal, so proxy it with an Actor-aware wrapper for
better scheduling.
|
|
WAvoid mucking with Unicorn::TeeInput, since other apps may
depend on that class, so we subclass it as Rainbows::TeeInput
and modify as necessary in worker processes.
For Revactor, remove the special-cased
Rainbows::Revactor::TeeInput class and instead emulate
readpartial for Revactor sockets instead.
|
|
commit a5f4d11cdb9465b1ffa2892b3d84ee53b8962930 in unicorn.git
switched all ivars to struct members for ease-of-hacking and
object size.
|
|
Less stuff to maintain is good.
|
|
Based on unicorn.git commit e4256da292f9626d7dfca60e08f65651a0a9139a
raise Unicorn::ClientShutdown if client aborts in TeeInput
Leaving the EOFError exception as-is bad because most
applications/frameworks run an application-wide exception
handler to pretty-print and/or log the exception with a huge
backtrace.
Since there's absolutely nothing we can do in the server-side
app to deal with clients prematurely shutting down, having a
backtrace does not make sense. Having a backtrace can even be
harmful since it creates unnecessary noise for application
engineers monitoring or tracking down real bugs.
|
|
We're doomed if the client socket EOFs on us while we're reading
it. So don't hide it and let the exception bubble all the way
up the stack.
|
|
Explicitly requested short reads may cause too much data to be
returned, which would be bad and potentially break the
application. We need to ensure proper IO#readpartial-like
semantics in both of these models.
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|