Rainbows! at a glance

Confused by all the options we give you? So are we! Here's some tables to help keep your head straight. Remember, engineering is all about trade-offs.

core features and compatibility

module	rack.input streaming	Ruby 1.8	Ruby 1.9	Rubinius	slow clients
Unicorn/Base	Yes	Yes	Yes	Yes	No
Revactor	Yes	No	Yes	No	Yes
ThreadPool	Yes	Yes	Yes	Yes	Yes
Coolio	No	Yes	Yes	No	Yes
ThreadSpawn	Yes	Yes	Yes	Yes	Yes
EventMachine	No	Yes	Yes	No	Yes
CoolioThreadSpawn	No	No	Yes	No	Yes
FiberSpawn	Yes	No	Yes	No	Yes
FiberPool	Yes	No	Yes	No	Yes
ActorSpawn	Yes	Not yet	No	Yes	Yes
NeverBlock	No	Yes	Yes	No	Yes
CoolioThreadPool	No	Yes	No	No	Yes
CoolioFiberSpawn	Yes	No	Yes	No	Yes
WriterThreadPool	Yes	Yes	Yes	Yes	no
WriterThreadSpawn	Yes	Yes	Yes	Yes	no
Epoll	no	Yes	Yes	Yes	Yes
XEpoll	no	Yes	Yes	Yes	Yes
XEpollThreadSpawn	Yes	Yes	Yes	Yes	Yes
XEpollThreadPool	Yes	Yes	Yes	Yes	Yes

• Cool.io should also work with Rubinius (though we haven't had time to test).
• CoolioThread* and CoolioThread* requires Ruby 1.9 reasonable performance
• rack.input streaming is what makes upload progress, and BOSH possible
• rack.input streaming is NOT compatible with current versions of nginx or any proxy that fully buffers request bodies before proxying. Keep in mind request body buffering in nginx is a good thing in all other cases where rack.input streaming is not needed.

application requirements

module	slow I/O (backend, not client)	thread safety	single thread reentrant
Unicorn/Base	avoid	No	No
Revactor	Coolio, Revactor, not Fiber::IO	No	Yes
ThreadPool	thread-safe Ruby	Yes	No
Coolio	Coolio	No	No
ThreadSpawn	thread-safe Ruby	Yes	No
EventMachine	EventMachine	No	No
CoolioThreadSpawn	thread-safe Ruby, Coolio	Yes	No
FiberSpawn	Rainbows::Fiber::IO	No	Yes
FiberPool	Rainbows::Fiber::IO	No	Yes
ActorSpawn	thread-safe Ruby	Yes	Yes
NeverBlock	NeverBlock, EventMachine	No	Yes
CoolioThreadPool	thread-safe Ruby, Coolio	Yes	No
CoolioFiberSpawn	Rainbows::Fiber::IO	No	Yes
WriterThreadPool	avoid	Maybe	Maybe
WriterThreadSpawn	avoid	Maybe	Maybe
Epoll	No	No	No
XEpoll	No	No	No
XEpollThreadSpawn	thread-safe Ruby	Yes	No
XEpollThreadPool	thread-safe Ruby	Yes	No

• Requirements for single thread reentrancy are loose in that there is no risk of race conditions and potentially mutually exclusive to thread-safety. In the case where a Fiber yields while holding a resource and another Fiber attempting to acquire it may raise an error or worse, deadlock the entire process.
• Slow I/O means anything that can block/stall on sockets including 3rd-party APIs (OpenID providers included) or slow database queries. Properly run Memcached (within the same LAN) is fast and not a blocker. Slow I/O on POSIX filesystems only includes a few operations, namely on UNIX domain sockets and named pipes. Nearly all other operations on POSIX filesystems can be considered "fast", or at least uninterruptible.
• WriterThread{Pool,Spawn} will require thread safety if your response body is dynamically generated during the body#each call.

middlewares and frameworks

model	DevFdResponse	AppPool	Rack::Lock	async
Unicorn/Base	no-op	no-op	no-op	lots of RAM :P
Revactor	no-op	Yes	No!	Revactor itself
ThreadPool	Yes	Yes	Yes	thread-safe Ruby
Coolio	Yes	no-op	no-op	DevFdResponse
ThreadSpawn	Yes	Yes	Yes	thread-safe Ruby
EventMachine	Yes	no-op	no-op	async_sinatra, Cramp, rack-fiber_pool
CoolioThreadSpawn	Yes	Yes	Dumb	thread-safe Ruby
FiberSpawn	Yes	Yes	No!	Rainbows::Fiber::IO, Rainbows.sleep
FiberPool	Yes	Yes	No!	Rainbows::Fiber::IO, Rainbows.sleep
ActorSpawn	no-op	Yes	Yes	thread-safe Ruby
NeverBlock	Yes	Yes*	Yes*	NeverBlock, async_sinatra
CoolioThreadPool	Yes	Yes	Dumb	Coolio, thread-safe Ruby
CoolioFiberSpawn	Yes	Yes	No!	Coolio, Rainbows::Fiber::IO, Rainbows.sleep
WriterThreadPool	Yes	no-op	no-op	thread-safe Ruby in response body only
WriterThreadSpawn	Yes	no-op	no-op	thread-safe Ruby in response body only
Epoll	Yes	no-op	no-op	DevFdResponse
XEpoll	Yes	no-op	no-op	DevFdResponse
XEpollThreadPool	Yes	Yes	Yes	thread-safe Ruby
XEpollThreadSpawn	Yes	Yes	Yes	thread-safe Ruby

• "No!" means it's fundamentally incompatible, use an AppPool :size of one instead.
• NeverBlock also supports a :pool_size option which is one less layer of complexity than using AppPool.
• NeverBlock can neuter the Mutex class so Rack::Lock effectively becomes a no-op with:
  require "never_block/frameworks/rails" (before Rails is loaded)
• Everything that's DevFdResponse-compatible can use it for passing async responses through

Originally generated with the Darkfish Rdoc Generator 2, modified by wrongdoc.

We love to hear from you!
Email patches (with git send-email), pull requests, questions, bug reports, suggestions, etc. to us publically at rainbows-talk@rubyforge.org.
No subscription to the mailing list is necessary, just let us know to Cc: you if you're unsubscribed.
To subscribe, email rainbows-talk-request@rubyforge.org with "subscribe" in the Subject and respond to the automated confirmation message.
Do not waste bandwidth with HTML, HTML mail will not be read.
Quote only parts you're responding to and do not top post.
For sensitive topics, email us privately at rainbows@bogomips.org.