notes for streaming responses with Rails 3.1

Eric Wong normalperson at
Fri Apr 29 20:44:53 EDT 2011

Eric Wong <normalperson at> wrote:
> == Rainbows! concurrency options
> === ThreadPool/ThreadSpawn

==== Linux-only

I also added XEpollThreadSpawn to rainbows.git which basically uses
epoll to maintain idle keepalive connections but is otherwise the same
as ThreadSpawn for "hot" connections (including streaming "rack.input"
and also streaming respond_body#each with no enforced userspace

==== Ruby 1.9 + Linux-only

The key advantage of the XEpoll* relying on epoll (and not more portable
things) is we can have one (native) thread stuck in epoll_wait() can be
woken up by another (native) thread adding to the epoll set with
epoll_ctl().  We combine this with the ability to do real blocking
accept() calls under 1.9 with "wake one" behavior[1] in the Linux
kernel, we can expect less contention and fairer load balancing across
multiple acceptors/processes.

The behavior I'm describing with multi-threading epoll isn't possible
with poll() or select().  I'm unsure about kqueue, nor do I know if
*BSDs implement "wake one" behavior with blocking accept() in the


Eric Wong

More information about the rainbows-talk mailing list