From 06de4af18d1ba3b28e49e9d8f700df4eca36e635 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Wed, 25 Nov 2009 12:14:21 -0800 Subject: Documentation updates for new concurrency models --- README | 24 ++++++++++++------------ TODO | 10 ++++------ lib/rainbows/fiber_pool.rb | 6 ++++-- lib/rainbows/fiber_spawn.rb | 5 +++-- lib/rainbows/rev_thread_spawn.rb | 3 ++- 5 files changed, 25 insertions(+), 23 deletions(-) diff --git a/README b/README index 58569bc..630a3d8 100644 --- a/README +++ b/README @@ -15,22 +15,22 @@ For network concurrency, models we currently support are: * {:Revactor}[link:Rainbows/Revactor.html] * {:ThreadPool}[link:Rainbows/ThreadPool.html] -* {:Rev}[link:Rainbows/Rev.html]* +* {:Rev}[link:Rainbows/Rev.html] * {:ThreadSpawn}[link:Rainbows/ThreadSpawn.html] * {:EventMachine}[link:Rainbows/EventMachine.html] +* {:RevThreadSpawn}[link:Rainbows/RevThreadSpawn.html] +* {:FiberSpawn}[link:Rainbows/FiberSpawn.html] +* {:FiberPool}[link:Rainbows/FiberPool.html] We have {more on the way}[link:TODO.html] for handling network concurrency. Additionally, we also use multiple processes (managed by Unicorn) for CPU/memory/disk concurrency. -\* our \Rev concurrency model is only recommended for slow clients, not -sleepy apps. Additionally it does not support streaming "rack.input" to -the application. - -For application concurrency, we have the Rainbows::AppPool Rack -middleware that allows us to limit application concurrency independently -of network concurrency. Rack::Lock as distributed by Rack may also be -used to limit application concurrency to one (per-worker). +For application concurrency with Thread-based models, we have the +Rainbows::AppPool Rack middleware that allows us to limit application +concurrency independently of network concurrency. Rack::Lock as +distributed by Rack may also be used to limit application concurrency to +one (per-worker). == Features @@ -53,7 +53,7 @@ used to limit application concurrency to one (per-worker). == Applications -\Rainbows is for the odd things Unicorn sucks at: +\Rainbows is mainly designed for the odd things Unicorn sucks at: * 3rd-party APIs (to services outside your control/LAN) * OpenID consumers (to providers outside your control/LAN) @@ -65,8 +65,8 @@ used to limit application concurrency to one (per-worker). * Long polling * Reverse Ajax -\Rainbows may also be used to service slow clients even with fast -applications using the \Rev concurrency model. +\Rainbows can also be used to service slow clients directly even with +fast applications. == License diff --git a/TODO b/TODO index 8a47a37..483bd6a 100644 --- a/TODO +++ b/TODO @@ -7,15 +7,13 @@ care about. unit tests, only integration tests that exercise externally visible parts. -* Rev + Thread - current Rev model with threading, which will give - us a streaming (but rewindable) "rack.input". - * EventMachine.spawn - should be like Revactor, maybe? -* Rev + callcc - current Rev model with callcc (should work with MBARI) +* {Packet,Rev,EventMachine}+Fibers -* Fiber support - Revactor already uses these with Ruby 1.9, also not - sure how TeeInput can be done with this. +* {Packet,Rev}ThreadPool + +* Rev + callcc - current Rev model with callcc (should work with MBARI) * Omnibus - haven't looked into it, probably like Revactor with 1.8? diff --git a/lib/rainbows/fiber_pool.rb b/lib/rainbows/fiber_pool.rb index 8c408b9..ff693fa 100644 --- a/lib/rainbows/fiber_pool.rb +++ b/lib/rainbows/fiber_pool.rb @@ -7,9 +7,11 @@ module Rainbows # A Fiber-based concurrency model for Ruby 1.9. This uses a pool of # Fibers to handle client IO to run the application and the root Fiber # for scheduling and connection acceptance. The pool size is equal to - # the number of +worker_connections+. This model supports a streaming + # the number of +worker_connections+. Compared to the ThreadPool + # model, Fibers are very cheap in terms of memory usage so you can + # have more active connections. This model supports a streaming # "rack.input" with lightweight concurrency. Applications are - # strongly advised to wrap slow all IO objects (sockets, pipes) using + # strongly advised to wrap all slow IO objects (sockets, pipes) using # the Rainbows::Fiber::IO class whenever possible. module FiberPool diff --git a/lib/rainbows/fiber_spawn.rb b/lib/rainbows/fiber_spawn.rb index d1c1ec0..969c05b 100644 --- a/lib/rainbows/fiber_spawn.rb +++ b/lib/rainbows/fiber_spawn.rb @@ -4,9 +4,10 @@ require 'rainbows/fiber' module Rainbows # Simple Fiber-based concurrency model for 1.9. This spawns a new - # Fiber for every client connection. This exports a streaming + # Fiber for every incoming client connection and the root Fiber for + # scheduling and connection acceptance. This exports a streaming # "rack.input" with lightweight concurrency. Applications are - # strongly advised to wrap slow all IO objects (sockets, pipes) using + # strongly advised to wrap all slow IO objects (sockets, pipes) using # the Rainbows::Fiber::IO class whenever possible. module FiberSpawn diff --git a/lib/rainbows/rev_thread_spawn.rb b/lib/rainbows/rev_thread_spawn.rb index 1dc4d0d..b6c5eca 100644 --- a/lib/rainbows/rev_thread_spawn.rb +++ b/lib/rainbows/rev_thread_spawn.rb @@ -1,7 +1,8 @@ # -*- encoding: binary -*- require 'rainbows/rev' -warn "Rainbows::RevThreadSpawn is extremely experimental" +RUBY_VERSION =~ %r{\A1\.8} and + warn "Rainbows::RevThreadSpawn does not work well under Ruby 1.8" module Rainbows -- cgit v1.2.3-24-ge0c7