Date | Commit message (Collapse) |
|
No need to allocate a proc every time when we can just
yield much more efficiently.
|
|
Constant strings mean the runtime won't have to allocate new
objects all the time since GC is currently the biggest
performance problem of Ruby 1.9.x in my experience.
|
|
chunked Transfer-Encoding is only valid for HTTP/1.1
|
|
We guarantee the Rack env will exist for the duration of
the request/response cycle, so we can just tweak
"rainbows.autochunk".
|
|
Rack::Utils::HeaderHash is still expensive, so avoid
forcing it on users since we can assume app/library
authors use normally-cased HTTP headers.
|
|
Hash#[] is slightly slower on the miss case due to calling
Hash#default (but faster for the hit case, probably because it
is inlined in 1.9).
|
|
No need to wrap regular files
|
|
Cool.io is the new name for Rev. We'll continue to support Rev
until Cool.io breaks backwards compatibility. Rev may not be
supported if Cool.io is.
|
|
Kgio 2.0.0 has a superior API and less likely to conflict or
blow up with other applications. Unicorn 3.x requires Kgio 2.x,
too.
|
|
Applications may use wait_readable-aware methods directly
to work with Rainbows!
|
|
First off we use an FD_MAP to avoid creating redundant IO
objects which map to the same FD. When that doesn't work, we'll
fall back to trapping Errno::EBADF and IOError where
appropriate.
|
|
/dev/fd/0 may not be stat()-able on some systems after dropping
permissions from root to a regular user. So just check for
"/dev/fd" which seems to work on RHEL 2.6.18 kernels. This also
allow us to be used independently of Unicorn in case somebody
ever feels the compelling need to /close/ stdin.
|
|
Proxying regular Ruby IO objects while Revactor is in use is
highly suboptimal, so proxy it with an Actor-aware wrapper for
better scheduling.
|
|
Some middlewares such as Clogger rely on wrapping the body
having the close method called on it for logging.
|
|
If a response proxying a pipe (or socket) includes a
Content-Length, do not attempt to outsmart the application
and just use the given Content-Length.
This helps avoid exposing applications to weird internals such
as env["rainbows.autochunk"] and X-Rainbows-* response headers.
|
|
|
|
IO#read always returns a binary string buffer if passed an
explicit length to read, and we always do that. This is
a small garbage reduction.
|
|
slowly cleaning up the generated RDoc
|
|
We can't use it effectively in Rubinius yet, and it's
broken due to the issue described in:
http://github.com/evanphx/rubinius/issues/379
|
|
There's no need to #dup the middleware object, just use
a custom Rainbows::DevFdResponse::Body object.
|
|
HeaderHash objects can only be used as headers without
violating Rack::Lint in Rack 1.1.0 or later.
|
|
This is like the traditional FiberSpawn, but more scalable (but
not necessarily faster) as it can use epoll or kqueue.
|
|
This is another Fiber-based concurrency model that can exploit
a streaming "rack.input" for clients. Spawning Fibers seems
pretty fast, but maybe there are apps that will benefit from
this.
|
|
This one seems a easy to get working and supports everything we
need to support from the server perspective. Apps will need
modified drivers, but it doesn't seem too hard to add
more/better support for wrapping IO objects with Fiber::IO.
|
|
This new middleware should be a no-op for non-Rev concurrency
models (or by explicitly setting env['rainbows.autochunk'] to
false).
Setting env['rainbows.autochunk'] to true (the default when Rev
is used) allows (e)poll-able IO objects (sockets, pipes) to be
sent asynchronously after app.call(env) returns.
This also has a fortunate side effect of introducing a code path
which allows large, static files to be sent without slurping
them into a Rev IO::Buffer, too. This new change works even
without the DevFdResponse middleware, so you won't have to
reconfigure your app.
This lets us epoll on response bodies that come in from a pipe
or even a socket and send them either straight through or with
chunked encoding.
|