Date | Commit message (Collapse) |
|
This means Rainbows::DevFdBody async responses and large
file streaming without slurping.
This is only with eventmachine 0.12.8, it looks like 0.12.10
changes the attach/watch API...
|
|
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.
|
|
It's more fool-proof this way and prevents us from using
idiotic/non-obvious concurrency model names.
|
|
This allows applications to determine which concurrency model
they're running under and possibly make adjustments accordingly.
The standard "rack.multithread" isn't enough for some
applications to determine what to do, especially when reentrancy
is required/recommended.
|
|
Various concurrency models work and scale differently, pick
counts that make a reasonable amount of sense...
|
|
:Base is default (along with the implied worker_connections=1).
This disallows nil for worker_connections, and makes.
|
|
This allows the server to be configured by doing something like
this inside an existing Unicorn configuration file:
Rainbows! do
use :Revactor
worker_connections 50
end
This should make it obvious we're using Rainbows-only features.
|
|
I didn't remember extend when this was originally implemented.
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|