From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Subject: Rainbows! at a glance summary document
Date: Thu, 26 Nov 2009 17:55:08 -0800 [thread overview]
Message-ID: <20091127015508.GA20733@dcvr.yhbt.net> (raw)
I just pushed this document out,
http://rainbows.rubyforge.org/Summary.html
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:
http://git.bogomips.org/cgit/rainbows.git/tree/Documentation/comparison.haml
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
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 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
_______________________________________________
rainbows-talk mailing list
rainbows-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
reply other threads:[~2009-11-27 1:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://yhbt.net/rainbows/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091127015508.GA20733@dcvr.yhbt.net \
--to=normalperson-rmlxzr9ms24@public.gmane.org \
--cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhbt.net/rainbows.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).