| Date | Commit message (Collapse) |
|---|
|
We use Cool.io internally everywhere now, but preserve
Rev-based models for anybody using them.
|
|
This is also our website, so we need to document the new
Cool.io-based concurrency options for users and point
existing Rev* users to it.
|
|
This should make classes easier to find and hopefully make
our code easier to follow.
|
|
While we're at it, unindent
|
|
Since we suck at building websites, we just rely on RDoc as a
website builder. And since Rainbows! is an application server
(and not a programming library), our internal API should be of
little interest to end users.
Anybody interested in Rainbows! (or any other project) internals
should be reading the source.
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
|
|
Patches submitted to rev-talk, awaiting feedback and
hopefully a new release.
|
|
Make sure app errors get logged correctly, and we no longer
return a 500 response when a client EOFs the write end (but not
the read end) of a connection.
|
|
|
|
Exposing a synchronous interface is too complicated for too
little gain. Given the following factors:
* basic ThreadSpawn performs admirably under REE 1.8
* both ThreadSpawn and Revactor work well under 1.9
* few applications/requests actually need a streaming "rack.input"
We've decided its not worth the effort to attempt to support
streaming rack.input at the moment. Instead, the new
RevThreadSpawn model performs much better for most applications
under Ruby 1.9
|
|
|
|
When reading 4K chunks, performance is dismal under 1.8
|
|
Somehow 1.8 performance blows with shorter reads in the Rack
application. This may be because the Rev framework uses
a default 16K IO size and our test applications may request
less.
|
|
Seems to pass all tests, but that may only mean our
test cases are lacking...
|