Rainbows! at a glance summary document

Eric Wong normalperson at yhbt.net
Thu Nov 26 20:55:08 EST 2009

I just pushed this document out,


You may note that it includes two Fiber-based concurrency models
currently in rainbows.git which will be in the next release :)

The source is in HAML[1] for now here:


Plain text (from w3m -dump) version here for convenience when
replying/annotating.  Let me know if there's anything I missed or
described wrong/sub-optimally.

---------------------------------- 8< -------------------------------
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      OK
Rev            No                   Yes      Yes      No       Yes
ThreadSpawn    Yes                  Yes      Yes      Yes      OK
EventMachine   No                   Yes      Yes      No       Yes
RevThreadSpawn No                   Slow     Yes      No       Yes
FiberSpawn     Yes                  No       Yes      Yes      Yes
FiberPool      Yes                  No       Yes      Yes      Yes

  • waiting on Rubinius for better signal handling
  • rack.input streaming is what makes upload progress, BOSH, and Web Sockets
  • 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       thread        single thread
                         client)               safety          reentrant
Unicorn/Base   avoid                        No           No
Revactor       Rev, Revactor, not Fiber::IO No           Yes
ThreadPool     thread-safe Ruby             Yes          No
Rev            Rev                          No           No
ThreadSpawn    thread-safe Ruby             Yes          No
EventMachine   EventMachine                 No           No
RevThreadSpawn thread-safe Ruby, Rev        Yes          No
FiberSpawn     Rainbows::Fiber::IO          No           Yes
FiberPool      Rainbows::Fiber::IO          No           Yes

  • 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.

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     no-op         Yes     Yes        standard Ruby
Rev            Yes           no-op   no-op      DevFdResponse
ThreadSpawn    no-op         Yes     Yes        standard Ruby
EventMachine   Yes           no-op   no-op      async_sinatra
RevThreadSpawn Yes           Yes     Dumb       standard Ruby
FiberSpawn     Yes           Yes     No!        Rainbows::Fiber{::IO,.sleep}
FiberPool      Yes           Yes     No!        Rainbows::Fiber{::IO,.sleep}

  • "No!" means it's fundamentally incompatible
  • Everything that's DevFdResponse-compatible can use it for passing async
    responses through
---------------------------------- 8< -------------------------------

[1] - not sure if there's a better/easier way of doing tables for HTML

Eric Wong

More information about the rainbows-talk mailing list