1 %h2 core features and compatibility
6 %th.tee rack.input streaming
54 %td.mod RevThreadSpawn
104 RevThread* + 1.8 performance is bad with Rev <= 0.3.1.
105 Rev 0.3.2 (when it is released) should be much faster under 1.8.
107 waiting on Rubinius for better signal handling
109 rack.input streaming is what makes
110 %a(href="http://upr.bogomips.org/") upload progress,
113 rack.input streaming is NOT compatible with current versions of nginx
114 or any proxy that fully buffers request bodies before proxying.
115 Keep in mind request body buffering in nginx is a good thing in all
116 other cases where rack.input streaming is not needed.
118 %h2 application requirements
123 %th.slowio slow I/O (backend, not client)
124 %th.thr thread safety
125 %th.reent single thread reentrant
134 %a(href="http://rev.rubyforge.org/")Rev,
135 %a(href="http://revactor.org/")Revactor,
138 %a(href="Rainbows/Fiber/IO.html")Fiber::IO
143 %td.slowio thread-safe Ruby
149 %a(href="http://rev.rubyforge.org/") Rev
154 %td.slowio thread-safe Ruby
160 %a(href="http://rubyeventmachine.com") EventMachine
164 %td.mod RevThreadSpawn
167 %a(href="http://rev.rubyforge.org/") Rev
173 %a(href="Rainbows/Fiber/IO.html") Rainbows::Fiber::IO
179 %a(href="Rainbows/Fiber/IO.html") Rainbows::Fiber::IO
184 %td.slowio thread-safe Ruby
190 %a(href="http://www.espace.com.eg/neverblock") NeverBlock,
191 %a(href="http://rubyeventmachine.com") EventMachine
195 %td.mod RevThreadPool
198 %a(href="http://rev.rubyforge.org/") Rev
202 %td.mod RevFiberSpawn
204 %a(href="Rainbows/Fiber/IO.html") Rainbows::Fiber::IO
210 Requirements for single thread reentrancy are loose in that there is
211 no risk of race conditions and potentially mutually exclusive to
212 thread-safety. In the case where a Fiber yields while holding a
213 resource and another Fiber attempting to acquire it may raise
214 an error or worse, deadlock the entire process.
216 Slow I/O means anything that can block/stall on sockets including
217 3rd-party APIs (OpenID providers included) or slow database queries.
218 Properly run Memcached (within the same LAN) is fast and not a blocker.
219 Slow I/O on POSIX filesystems only includes a few operations, namely
220 on UNIX domain sockets and named pipes. Nearly all other operations
221 on POSIX filesystems can be considered "fast", or at least
224 %h2 middlewares and frameworks
231 %a(href="Rainbows/DevFdResponse.html") DevFdResponse
233 %a(href="Rainbows/AppPool.html") AppPool
235 %a(href="http://rack.rubyforge.org/doc/Rack/Lock.html") Rack::Lock
243 %td.async lots of RAM :P
250 %td.async Revactor itself
257 %td.async standard Ruby
264 %td.async DevFdResponse
271 %td.async standard Ruby
278 %td.async async_sinatra
281 %td.mod RevThreadSpawn
285 %td.async standard Ruby
292 %td.async Rainbows::Fiber::IO, Rainbows.sleep
299 %td.async Rainbows::Fiber::IO, Rainbows.sleep
306 %td.async standard Ruby
313 %td.async NeverBlock, async_sinatra
316 %td.mod RevThreadPool
320 %td.async standard Ruby
323 %td.mod RevFiberSpawn
327 %td.async Rainbows::Fiber::IO, Rainbows.sleep
331 "No!" means it's fundamentally incompatible, use an
332 %a(href="Rainbows/AppPool.html") AppPool
336 NeverBlock also supports a :pool_size option which is one less
337 layer of complexity than using AppPool.
339 NeverBlock can neuter the Mutex class so Rack::Lock effectively
340 becomes a no-op with:
342 %code require "never_block/frameworks/rails"
343 (before Rails is loaded)
345 Everything that's DevFdResponse-compatible can use it for passing
346 async responses through